Re: [Flightgear-devel] releases +- bugs
On 2 Dec 2009, at 06:34, Ron Jensen wrote: | 39 – model capitalization – | observed: 19 Dec 2008 | again: 31 Oct 2009 |For example: when specifying the option --aircraft=dhc2W, the |dhc must not be capitalized, while the W must be capitalized. The value used for --aircraft is the file name of the -set.xml file. The command line user can ask flightgear for the value by --show-aircraft. The power user can list the aircraft folder and figure it out for himself. The novice should be using FGRun and avoiding this unpleasantness altogether. OPINION. Actually this one bites me regularly, I was planning to do it when I have a spare moment. James -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound system improvements...levels, sources, balancing, and devices...
On 2 Dec 2009, at 07:40, Erik Hofman wrote: Secondly, I think it would be beneficial to have the ability to specify a sound device for a certain group. So you could, for example, send aircraft sounds to your speakers, and radio sounds to a headset. Could be done with the current code but is low proirity for me. The only useful split I know of, is radio sounds separate to 'cockpit/exterior' sounds. That's actually why I was working on fgcom device support on Mac - my preferred setup is FG sounds from my line out (which goes to speakers, including a sub, for nice rumble) and all fgcom through my USB headset. Unfortunately this doesn't work due to aforementioned OpenAL laziness on the part of Apple ... so I'm stuck with fgcom coming out of the main speakers, which is much header to discern above cockpit / engine noise just like RL I guess. Anyway, since fgcom is a separate process, this is not much to do with FG - except that ideally ATIS and other services would *also* be delivered via FGCom, which would clean up a whole bunch of things. James -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound system improvements...levels, sources, balancing, and devices...
James Turner wrote: On 2 Dec 2009, at 07:40, Erik Hofman wrote: Secondly, I think it would be beneficial to have the ability to specify a sound device for a certain group. So you could, for example, send aircraft sounds to your speakers, and radio sounds to a headset. Could be done with the current code but is low proirity for me. The only useful split I know of, is radio sounds separate to 'cockpit/exterior' sounds. That's actually why I was working on fgcom device support on Mac - my preferred setup is FG sounds from my line out (which goes to speakers, including a sub, for nice rumble) and all fgcom through my USB headset. Unfortunately this doesn't work due to aforementioned OpenAL laziness on the part of Apple ... so I'm stuck with fgcom coming out of the main speakers, which is much header to discern above cockpit / engine noise just like RL I guess. Anyway, since fgcom is a separate process, this is not much to do with FG - except that ideally ATIS and other services would *also* be delivered via FGCom, which would clean up a whole bunch of things. To go a bit into the technical details: It is already possible to create a second SoundMgr class and initialize it with a different device name. Now you have two different sound output devices to which you can assign SampleGroups to. Erik -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] releases +- bugs
Do what ? This was brought up in the past , and I suggested changing it to dhc2-wheels , etc ... but dont remember getting much feedback about it ... and I dont have much patience if those people pointing out bugs cant follow through and assist in coming up with a solution if they are able. I'll change these tomorrow in cvs to -wheels ,-skis , etc , where applicable. On 12/2/09, James Turner zakal...@mac.com wrote: On 2 Dec 2009, at 06:34, Ron Jensen wrote: | 39 – model capitalization – | observed: 19 Dec 2008 | again: 31 Oct 2009 |For example: when specifying the option --aircraft=dhc2W, the |dhc must not be capitalized, while the W must be capitalized. The value used for --aircraft is the file name of the -set.xml file. The command line user can ask flightgear for the value by --show-aircraft. The power user can list the aircraft folder and figure it out for himself. The novice should be using FGRun and avoiding this unpleasantness altogether. OPINION. Actually this one bites me regularly, I was planning to do it when I have a spare moment. James -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] releases +- bugs
syd adams wrote: Do what ? This was brought up in the past , and I suggested changing it to dhc2-wheels , etc ... but dont remember getting much feedback about it ... and I dont have much patience if those people pointing out bugs cant follow through and assist in coming up with a solution if they are able. I'll change these tomorrow in cvs to -wheels ,-skis , etc , where applicable. Hi Syd, I think the suggestion is that this is fixed in the code, so you don't need to change any of your -set.xml files. So, the following arguments would all work: --aircraft=dhc2w --aircraft=dhc2W --aircraft=DHC2W Of course, if you think that dhc2-ski is better than dhc2s, then that's obviously your decision, but that's a different issue to the one John brought up. -Stuart -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] releases +- bugs
On 2 Dec 2009, at 09:19, Stuart Buchanan wrote: Of course, if you think that dhc2-ski is better than dhc2s, then that's obviously your decision, but that's a different issue to the one John brought up. Agreed on all counts - I will fix the case-sensitivity, but other issues are up to the aircraft developer! James -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] releases +- bugs
Stuart Buchanan wrote: So, the following arguments would all work: --aircraft=dhc2w --aircraft=dhc2W --aircraft=DHC2W Of course, if you think that dhc2-ski is better than dhc2s, then that's obviously your decision, but that's a different issue to the one John brought up. -Stuart Years ago I tweaked my local FG so that it first did a case sensitive search for aircraft (to cover the case that you had a c172 and a C172 which were different), and then if it found nothing in that search, it did a case insensitive search. I seem to remember that this was 5 or 6 lines of extra code, but I don't have that source tree any more. Richard This e-mail has been scanned for all viruses by Star. 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 -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound system improvements...levels, sources, balancing, and devices...
First, we really need better control of sound levels and balancing between different sound sources. It is often impossible to hear ATIS over the aircraft sounds for example. Having one master volume control and volume properties on the radios is not enough. I think breaking it into different groups of sounds...aircraft, radios, etc...and having master controls for each would be a good solution. Not a bad idea. Good thing that is what I've implemented in the past months and which is in CVS now. So you've already implemented separate master sound controls for radios and aircraft and/or other groups already...such as would be configurable from the sound config dialog? My copy of CVS doesn't currently include the new sound system...so if so that's awesome..and just ignore me then. ;) Secondly, I think it would be beneficial to have the ability to specify a sound device for a certain group. So you could, for example, send aircraft sounds to your speakers, and radio sounds to a headset. Could be done with the current code but is low proirity for me. Understandable The only useful split I know of, is radio sounds separate to 'cockpit/exterior' sounds. Yes, currently only aircraft and radio sounds are logical groups, but it's also possible others could exist in the future. So it could be beneficial to have it setup so to be extended easily with more independently adjustable groups down the road I guess. That's actually why I was working on fgcom device support on Mac - my preferred setup is FG sounds from my line out (which goes to speakers, including a sub, for nice rumble) and all fgcom through my USB headset. Unfortunately this doesn't work due to aforementioned OpenAL laziness on the part of Apple ... so I'm stuck with fgcom coming out of the main speakers, which is much header to discern above cockpit / engine noise just like RL I guess. This is exactly my setup in linux already, flightgear outputs to my surround sound system, and fgcom outputs to my usb headset. I also have it configured so I can use fgcom with comm1 and comm2 simultaneously, comm1 to left channel, comm2 to right channel...selectable at run time which I transmit on. So if I could get flightgear to send radio sounds to my headset as well I'd be a very happy guy.. :) Anyway, since fgcom is a separate process, this is not much to do with FG - except that ideally ATIS and other services would *also* be delivered via FGCom, which would clean up a whole bunch of things. It would be neat if fgcom (or future replacement) implemented atis somehow. Yet not everyone uses fgcom so flightgear needs it's own atis still obviously, which might lead to strange results when I tune my radio to atis and flightgear AND fgcom start giving me weather info at the same time. :D To go a bit into the technical details: It is already possible to create a second SoundMgr class and initialize it with a different device name. Now you have two different sound output devices to which you can assign SampleGroups to. This sounds really good, so the code to make independant groups with different devices is therejust needs an interface configurable through gui to manage it. It would be awesome to have the sound config dialog show a master volume slider for each group, as well as a drop down to select a device for that group. If changing the devices at run time is problematic, command line options to set it at start up would be acceptable as well I guess. cheers! --Jacob -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound system improvements...levels, sources, balancing, and devices...
On Wed, Dec 2, 2009 at 7:52 AM, Erik Hofman e...@ehofman.com wrote: You really should use CVS.. Erik I do. :) Though I do so selectively as to keep it usable for me and to avoid conflicts with my personal modifications. So no, I'm not 100% inline with current cvs, including I haven't yet merged in the new sound system. The sound system, and some other changes, made flightgear mostly unusable previously, though looks like it's stabilizing a bit now so I should make a new migration soon. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound system improvements...levels, sources, balancing, and devices...
On Wed, Dec 2, 2009 at 2:07 PM, Jacob Burbach jmburb...@gmail.com wrote: On Wed, Dec 2, 2009 at 7:52 AM, Erik Hofman e...@ehofman.com wrote: You really should use CVS.. I do. :) Though I do so selectively as to keep it usable for me and to avoid conflicts with my personal modifications. So no, I'm not 100% inline with current cvs, including I haven't yet merged in the new sound system. Nah, you should be using git :) Then you could easily track the current development version while also having your own branch. -- Csaba/Jester -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frequent segfaults in latest flightgear
On Wed, Dec 2, 2009 at 12:57 AM, Tim Moore wrote: Just to be clear, are you running with CullThreadPerCameraDrawThreadPerContext, or what? How many of each? Hi Tim, I was running with AutomaticSelection and only had a single display enabled: --prop:/sim/rendering/multithreading-mode=AutomaticSelection I've checked in a fix that should prevent the GUI drawing code from running at the same time as code that might manipulate its state; give it a try. After removing the above option from my .fgfsrc file I haven't seen a crash with the dialog boxes. You're not trying to do something weird like run the GUI on more than one screen, are you? No, not yet, but that would be a great feature request. Also being able run additional 2d panels on extra displays, but that's a very low priority for me at the moment, devices like the matrox triplehead to go and nvidia-twinview help reduce the need for a software solution. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound system improvements...levels, sources, balancing, and devices...
On Wed, Dec 2, 2009 at 8:29 AM, Csaba Halász csaba.hal...@gmail.com wrote: On Wed, Dec 2, 2009 at 2:07 PM, Jacob Burbach jmburb...@gmail.com wrote: On Wed, Dec 2, 2009 at 7:52 AM, Erik Hofman e...@ehofman.com wrote: You really should use CVS.. I do. :) Though I do so selectively as to keep it usable for me and to avoid conflicts with my personal modifications. So no, I'm not 100% inline with current cvs, including I haven't yet merged in the new sound system. Nah, you should be using git :) Then you could easily track the current development version while also having your own branch. -- Csaba/Jester Yes, but that's only recently become an option with flightgear and I haven't felt bothered enough to move yet. ;) -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Model diffuse and ambient colors
I've been playing around with the Rascal aircraft model, but it appears that it's never had it's materials updated and thus looks very dark on the non-illuminated sides. Is there a howto posted somewhere that explains how to fix this? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Model diffuse and ambient colors
Curtis Olson wrote:
I've been playing around with the Rascal aircraft model, but it appears
that it's never had it's materials updated and thus looks very dark on
the non-illuminated sides. Is there a howto posted somewhere that
explains how to fix this?
There's even a script floating around:
#! /bin/sh
for f in $@ ; do
sed -i.before-color-change
's,\(MATERIAL.*\)rgb\(.*\)amb\(.*\)emis\(.*\)spec\(.*\)shi\(.*\)trans\(.*\)$,\1rgb\2amb\2emis\4spec\5shi\6trans\7,1'
$f
if ! cmp ${f} ${f}.before-color-change /dev/null 21 ; then
echo $f has changed colors!
fi
done
Erik
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Model diffuse and ambient colors
2009/12/2 Curtis Olson curtol...@gmail.com:
non-illuminated sides. Is there a howto posted somewhere that explains how
to fix this?
Some time ago I found this in devel-list:
#! /bin/sh
for f in $@ ; do
sed -i.before-color-change
's,\(MATERIAL.*\)rgb\(.*\)amb\(.*\)emis\(.*\)spec\(.*\)shi\(.*\)trans\(.*\)$,\1rgb\2amb\2emis\4spec\5shi\6trans\7,1'
$f
if ! cmp ${f} ${f}.before-color-change /dev/null 21 ; then
echo $f has changed colors!
fi
done
--
---
WBR, Vadym.
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Model diffuse and ambient colors
or just set the amb color to the same as rgb in the .ac file.
On 12/2/09, Curtis Olson curtol...@gmail.com wrote:
Thanks Vadym and Erik, hopefully this does the trick.
Curt.
On Wed, Dec 2, 2009 at 8:46 AM, Vadym Kukhtin val...@gmail.com wrote:
2009/12/2 Curtis Olson curtol...@gmail.com:
non-illuminated sides. Is there a howto posted somewhere that explains
how
to fix this?
Some time ago I found this in devel-list:
#! /bin/sh
for f in $@ ; do
sed -i.before-color-change
's,\(MATERIAL.*\)rgb\(.*\)amb\(.*\)emis\(.*\)spec\(.*\)shi\(.*\)trans\(.*\)$,\1rgb\2amb\2emis\4spec\5shi\6trans\7,1'
$f
if ! cmp ${f} ${f}.before-color-change /dev/null 21 ; then
echo $f has changed colors!
fi
done
--
---
WBR, Vadym.
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Can someone please add missing terrasync scenery
Hi, Jari Häkkinen wrote: Terragear complains about missing directory in the subversion repository: URL 'http://terrascenery.googlecode.com/svn/trunk/data/Scenery/Objects/e010n50/e014n54' doesn't exist Can someone please add it? We don't have any objects available in this area, therefore we don't offer the Objects-part of this tile for download. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound system improvements...levels, sources, balancing, and devices...
Ok, so I went ahead and did a build of the latest and greatest...looks (and sounds) really good. I love when when features are implemented faster than I can ask for them! ;) A couple observations: 1. Cannot adjust volume of atis(comm radios) from sound config dialog. Not a major issue I guess since I can mostly tune it with increasing master and lowering effects/avionics. Can also adjust with the actual comm volume control of course, but not all aircraft have working radio controls. Having to monkey with the levels of all other volume controls to get comm volumes proper, and possibly having to make fine adjustments to comm volume from property manager does raise some usability issues though. Might be worth adding a comm radio control to the sound config dialog as well. 2. Adjusting the volume of the comm radios causes the atis to jump to a different position in her dialog...doh! Other than that everything seemed to be working pretty well(sound wise anyway)thanks for all your hard work! I know you said different devices per group are not a priority for you, but if you could work it onto your todo list for the future that would be great. I'm sure I'm not the only one who would find this extremely useful. cheers! --Jacob -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
