Re: [Flightgear-devel] condition/mixture control
* SydSandy -- Monday 28 January 2008: Does anyone have any objection to binding the mixture M/m control to the Condition control , since they both are fuel controls on different engines ? I object. The functions controls.mixtureAxis() and controls.adjMixture() should only do what their name says. If you want to use the mixture property for condition, then either just redefine the wrappers (whereby the conditionAxis() function would yet have to be defined) controls.adjMixture = controls.adjCondition; controls.mixtureAxis = controls.conditionAxis; or use the mixture property in the FDM config file instead of the condition property (with a comment explaining it): - control-setting axis=/controls/engines/engine[0]/condition value=1.0/ + control-setting axis=/controls/engines/engine[0]/mixture value=1.0/ m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] trees
--- Tim Moore wrote: Curtis Olson wrote: | Definitely ... we could vary them in shape and appearance, not just | color. There is much that can be done. Already supported. The current patch allows different shapes and appearance. The reason that the trees currently just vary by colour is entirely due to my level of artistic ability. If you have a look in the data/Textures/Trees/ directory you will see that the .rgb files are actually a strip of different trees, evenly distributed along the x-axis. You can change them in any way you want, as long as you ensure that they are evenly spaced, and you update the tree-varieties tag in materials.xml to match. In fact, it would be great if someone with some artistic skill could work on the textures. You can even vary the distribution of the different tree types by including similar textures multiple times. | (I haven't dug much in the code for these trees, but ...) it appears | that the random locations are computed as areas come into view (or come | close enough to the viewer.) So each time a new chunk of trees are | added, I see a blip in the frame rates. If there are a lot of chunks | that need to be added, that translates into a lot of blips. Would it be | possible to compute the locations of the trees when the tile is loaded | (in the load thread) and always have these structures available when | needed? Now that we can have such wide tree coverage, we'll be burning | the memory for these structures anyway. Previously, David's code only | built the random object structures for areas close by because having all | the random object structures for all the tiles in memory simultaneously | would be a huge waste. I suspect the plib based random object scene | graph structures were much more wasteful than the structures needed by | the OSG shader based approach. The locations are computed when the tile is loaded. I think the blips you're seeing are caused by compiling a new shader program per chunk of trees. That problem should go away when the code is integrated into cvs. I think the current patch has already fix this. A single osg::Program which includes the Shaders is instantiated the first time any trees are generated, and re-used after that point... unless OSG is doing something particularly silly, or my code is bugged. The blips are more likely due to the generation of the huge number of trees when the tile is loaded. I haven't counted them, but we must be generating hundreds of thousands for some tiles. BTW - the current patch is more efficient in this respect as well. -Stuart ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] trees
--- Curtis Olson wrote: In this case the trees aren't so much loaded ... there's only one small texture that defines the trees (or group of randomized tree images.) What does need to be done is that a set of random locations needs to be generated across the surface of each tile ... and this needs to happen sometime after the terrain is loaded. Right now this appears to be done in the main render thread once the polygons get within some visible distance (although the behavior of this is slightly weird and you can be ontop of an area before the trees are actually generated.) The tree locations are generated when the tile is loaded, not when they come into view. The tree visibility is a problem I'm still trying to solve. Currently I create a 32x32 quadtree across the extent of the trees within the tile. If there are trees at each corner of the tile, that effectively means that the tile is split into a straightforward 32x32 grid. Each rectangle in the grid is a LoD node with a range of 8000m, under which are all the trees within that space, within a Group node. So, all the trees in the rectangle become visible when you get within 8000m of the center of the rectangle. I _think_ that sometimes the center of the rectangle is more than 8000m from the edge, which is why you can be ontop of the area before they appear. However, in some cases I've see the area I am on top of _not_ have trees, even though the areas to either side do, or the visibility of the trees depends on the direction I'm looking. I'm not sure the reason for this - it could be that the LoD loader is catching up, or something. BTW - could someone tell me the maximum size of a tile, in km? If people want to experiment with different settings: - TreeBin.hxx line 57 (#define SG_TREE_QUAD_TREE_SIZE 32) defines the size of the grid. - materials.xml line 96 (tree-range-m8000/tree-range-m) defines the LoD range for the trees. I'm thinking of changing the approach so that instead of working out the extent of the grid from the set of trees, we simply create a NxN grid across the tile, put the trees in appropriately, and then remove the empty nodes. This would have the advantage of improving performance when the tile is loaded: Currently we iterate through the list of trees twice - once to work out the extent of the grid, and then again to place the trees in the correct rectangle. Alternative approaches and any comments would be gratefully received. -Stuart ___ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Log Stream patch
--- Curtis Olson wrote: On Jan 27, 2008 3:51 AM, Frederic Bouvier wrote: Stuart Buchanan a écrit : Hi All, One of the frustrations of using Windows for development is the lack of a sensible way to re-direct stderr to a file. This is particularly annoying if you want to use a --log-level=debug. To fix this, I've changed the global_logstream to use stdout for windows only. Is there a reason why we shouldn't do that for unix too ? is stdout used for something else than logging ? The patch below does this. If someone could test that this doesn't mess up *nix, and commit it, that would be great. If we can avoid #ifdef, it's better isn't it ? I don't mind writing these messages to stdout versus stderr, On unix you can just run program file 21 in order to capture stderr as well as stdout. Is that not possible in windows? I bet a cygwin shell could do this. No, it isn't possible in a normal command shell on windows, though it's easy in a cygwin shell. One reason for switching to stdout for windows is that it will help supporting the windows community. It'll be much easier to ask them to put c:\temp\fgfs.txt at the end of their command line (or within fgrun - is that possible?) than get them to install cygwin :) I don't have any opinion as to whether we should have all output on all platforms go to stdout. It would be consistent. -Stuart ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] trees
hi since i'm already much into memory-stuff i'll add my 2 cents... On Sunday 27 January 2008, Curtis Olson wrote: ... Would it be possible to compute the locations of the trees when the tile is loaded (in the load thread) and always have these structures available when needed? Now that we can have such wide tree coverage, we'll be burning the memory for these structures anyway. from my first research it seems like we are burning *lots* of memory for the trees. enabling trees results in about 137 mb of aditional allocations. with trees, valgrind reports 818 mb of allocations. this count is the figure i get from starting fg, waiting for the scenerey to be loaded and letting it run for another 10 frames before exiting with fgOSExit(0). also it is important to note that the figure shows all memory that is being allocated (on the heap, as far as i can tell). so it also shows temporary allocations. i don't have the time to dig deeper here right now. i just wanted to make these firures visible for those concerned. also note that this is with the first tree implementation (one-texture-version), i haven't tried the current one yet. ... On Sunday 27 January 2008, Curtis Olson wrote: One of the reasons (I think) that OSG start up times are so long is that the loading is getting interleaved with the FDM and everything else, but we aren't actually showing the view until the loader has loaded enough data. So there is much wasted effort at the beginning until enough terrain is loaded and the splash screen is removed and the terrain actually drawn. This code has grown really complex over the years, but at some point, now that we are using OSG, it might be worth revisiting some of these earlier design choices. They made sense for a plib world, but perhaps not for an OSG world with better threading support. you are very much right on this one. probably a week ago i have modified the main loop do delay everything else until the scenery is loaded. startup time is a lot better this way (14 vs. 11 secs on the fast machine) -- and from my impressions it doesn't seem to break anything. i will dig deeper into this if noone oppoeses. might take some time though, as we just got our second son :-) i think flightgear could really benefit from a rewrite or restructuring of Main. also since we are not near a release yet (is that right?), we do not need to fear this. all together i believe we have a lot of people running cvs versions. cvs can move fast until the next release is being prepared. regards, - till - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] trees
--- Stuart Buchanan [EMAIL PROTECTED] schrieb: In fact, it would be great if someone with some artistic skill could work on the textures. You can even vary the distribution of the different tree types by including similar textures multiple times. Sebastian Bechthold had nice trees in a package some time ago- can be found somewhere in the german forum. Maybe he is reading it, so he can provide it again... I have a copy, but without his permission I won't upload it... HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Ihr erstes Fernweh? Wo gibt es den schönsten Strand? www.yahoo.de/clever - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] trees
Quoting AJ MacLeod : On Monday 28 January 2008 11:02:11 Stuart Buchanan wrote: The current patch is a bit better for memory usage IIRC, but it is still quite hefty - a side-effect of generating all the trees at once for the tile. By all means we should be careful about needless memory usage / wastage (and perhaps features that demand lots of memory should be disabled by default.) At the same time, memory is extremely cheap, (mostly) easy to upgrade and modern PCs are generally equipped with huge amounts of it. If nice new features require lots of memory to work well and are optional, I don't see any particular problem... Don't forget that if you run a 32-bit system, a process is limited to 2Gb of virtual memory, not matter the actual physical memory. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] trees
On Monday 28 January 2008 11:02:11 Stuart Buchanan wrote: The current patch is a bit better for memory usage IIRC, but it is still quite hefty - a side-effect of generating all the trees at once for the tile. By all means we should be careful about needless memory usage / wastage (and perhaps features that demand lots of memory should be disabled by default.) At the same time, memory is extremely cheap, (mostly) easy to upgrade and modern PCs are generally equipped with huge amounts of it. If nice new features require lots of memory to work well and are optional, I don't see any particular problem... Cheers, AJ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] trees
--- till busch wrote: hi since i'm already much into memory-stuff i'll add my 2 cents... On Sunday 27 January 2008, Curtis Olson wrote: ... Would it be possible to compute the locations of the trees when the tile is loaded (in the load thread) and always have these structures available when needed? Now that we can have such wide tree coverage, we'll be burning the memory for these structures anyway. from my first research it seems like we are burning *lots* of memory for the trees. enabling trees results in about 137 mb of aditional allocations. with trees, valgrind reports 818 mb of allocations. this count is the figure i get from starting fg, waiting for the scenerey to be loaded and letting it run for another 10 frames before exiting with fgOSExit(0). also it is important to note that the figure shows all memory that is being allocated (on the heap, as far as i can tell). so it also shows temporary allocations. i don't have the time to dig deeper here right now. i just wanted to make these firures visible for those concerned. also note that this is with the first tree implementation (one-texture-version), i haven't tried the current one yet. The current patch is a bit better for memory usage IIRC, but it is still quite hefty - a side-effect of generating all the trees at once for the tile. -Stuart __ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Air Traffic Control (ATC ). Fixing bugs andadding new features.
Thanks for your answer. Last week i realised requesting departure and take-off clearance for Tower-ATC. Now i'm working on requesting landing for Approach-ATC. User will choose what type of approach he want to make: ILS (if so), NDB (if so), VFR (already realised in FG ;)), etc... Will send the patches when will end this work. Best, Daniyar -Original Message- From: Melchior FRANZ [EMAIL PROTECTED] To: flightgear-devel@lists.sourceforge.net Date: Sun, 27 Jan 2008 23:16:42 +0100 Subject: Re: [Flightgear-devel] Air Traffic Control (ATC). Fixing bugs andadding new features. * Daniyar Atadjanov -- Saturday 19 January 2008: This (attached) diff fixes only two (little) bugs in Tower-ATC: Ah, great. (Will commit after testing.) But this is a very little changes. What about other new feature to make ATC more realistic? This whole subsystem isn't maintained at the moment. You can make whatever changes are useful, or even rewrite the whole system. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Log Stream patch
On Jan 28, 2008 10:32 AM, Stuart Buchanan [EMAIL PROTECTED] wrote: --- Curtis Olson wrote: On Jan 27, 2008 3:51 AM, Frederic Bouvier wrote: Stuart Buchanan a écrit : Hi All, One of the frustrations of using Windows for development is the lack of a sensible way to re-direct stderr to a file. Isn't the cmd.exe the normal shell? http://technet.microsoft.com/en-us/library/bb490982.aspx From this it seems to me windows supports similar (if not same!) syntax for redirection. -- Csaba/Jester - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] condition/mixture control
On Mon, 28 Jan 2008 09:39:46 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: * SydSandy -- Monday 28 January 2008: Does anyone have any objection to binding the mixture M/m control to the Condition control , since they both are fuel controls on different engines ? I object. The functions controls.mixtureAxis() and controls.adjMixture() should only do what their name says. If you want to use the mixture property for condition, then either just redefine the wrappers (whereby the conditionAxis() function would yet have to be defined) controls.adjMixture = controls.adjCondition; controls.mixtureAxis = controls.conditionAxis; or use the mixture property in the FDM config file instead of the condition property (with a comment explaining it): - control-setting axis=/controls/engines/engine[0]/condition value=1.0/ + control-setting axis=/controls/engines/engine[0]/mixture value=1.0/ m. OK. Nothing serious , just thought i'd ask ... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] condition/mixture control
As a third possibility, you could define a simple alias in the *-set.xml file: controls engines engine n=0 condition alias=/controls/engines/engine[0]/mixture/ /engine /engines /controls Then you can use the condition property as much as you like, while the controls wrappers don't have to be modified. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] condition/mixture control
On Mon, 28 Jan 2008, Melchior FRANZ wrote: * SydSandy -- Monday 28 January 2008: Does anyone have any objection to binding the mixture M/m control to the Condition control , since they both are fuel controls on different engines ? I object. The functions controls.mixtureAxis() and controls.adjMixture() should only do what their name says. Hi, I have a somewhat related question: In the current controls.nas mixtureAxis(), propellerAxis() and carbHeatAxis() operate on all engines, while throttleAxis() operates only on selected engines. IMHO the former functions ought to behave like the latter and only affect the selected engines. Or do multi engine aircraft usually have no way to control those parameters for individual engines? Cheers, Anders -- --- Anders Gidenstam mail: anders(at)gidenstam.org WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] trees
* Maik Justus -- Monday 28 January 2008: The texture is scaled (mip mapping?), and therefore the new alpha value is interpolated between the original values resulting in semi-transparent values. You could set the alpha threshold appropriately: $ man glAlphaFunc (or whatever the OSG equivalent is) m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] trees
On Jan 28, 2008 2:18 PM, Maik Justus wrote: The transparency--bug appears only, where the alpha channel of the texture is neither 0 nor 100%. Therefore I changed the alpha channel to be only zero or 100%. But the problem is not solved. The texture is scaled (mip mapping?), and therefore the new alpha value is interpolated between the original values resulting in semi-transparent values. If it would be possible to exclude the alpha channel of the tree-textures from the interpolation, the transparency problem could be solved fully without any sorting (just by changing the textures). If it is not possible: sorting of the triangles within each tree would help in many cases. If you removed the transparency entirely then I believe that the edges of all the trees will develop aliasing artifacts ... kind of like if they were drawn with polygons. And as the mipmapping switches levels you might see additional odd artifacts. I'm pretty sure that if Stuart/Tim switch around the draw order so that the terrain is drawn first, then the problem will all but go away. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] trees
Hi Stuart, Stuart Buchanan schrieb am 28.01.2008 10:25: If you have a look in the data/Textures/Trees/ directory you will see that the .rgb files are actually a strip of different trees, evenly distributed along the x-axis. You can change them in any way you want, as long as you ensure that they are evenly spaced, and you update the tree-varieties tag in materials.xml to match. The transparency--bug appears only, where the alpha channel of the texture is neither 0 nor 100%. Therefore I changed the alpha channel to be only zero or 100%. But the problem is not solved. The texture is scaled (mip mapping?), and therefore the new alpha value is interpolated between the original values resulting in semi-transparent values. If it would be possible to exclude the alpha channel of the tree-textures from the interpolation, the transparency problem could be solved fully without any sorting (just by changing the textures). If it is not possible: sorting of the triangles within each tree would help in many cases. Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Virtual Flashmob
Hi there, Curt's idea of New Year's Day Funflight turned my fantasy on, and now I have another idea. :) Let's organize a virtual flashmob. My idea is to make KSFO's 28R clean of snow by a lot of snowplows. There would be no scoring, no race, only fun. :) There could be an ATC online letting pilots know about 28R is closed for cleaning due to heavy snowstorm. :) Then a dozen of snowplows turn onto the rwy, go along as fast as possible, and leave the rwy at the other end. :) The date could be 1600Z 02/02/2008, next Saturday. Anyone want to join? Cheers, Gabor aka KoverSrac - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Problem with compiling OSG
Hi, On Sun, Jan 27, 2008 at 07:34:29PM +0100, Mathieu Aguesse wrote: Hi, I had the same problem today: last week OSG compiled fine, but no more today. After several attempts to resolve this point I discovered that if I try to compile OSG with CMake 2.4.8 it works fine. If there is no real requirement to use the current CMake development dist, you can tell fgfs-builder to get the CMake-2-4-8 version from CVS. Thanks! Seems that the problem was fixed inside CMake 2.4.8 because with the last CVS release it works again. I thaught it is a problem inside OSG... regards, Holger Regards, Mathieu Le 25 janv. 08 à 07:49, Holger Wirtz a écrit : Hi, since yesterday I have some trouble to compile OSG: ... make[7]: Entering directory `/usr/local/src/fgfs-builder-20080118/build/OpenSceneGraph' Linking CXX shared library ../../lib/libosg.so /usr/bin/ld: cannot find -l-Wl,-rpath,/usr/local/src/fgfs-builder-20080118/build/ OpenSceneGraph/lib collect2: ld returned 1 exit status make[7]: *** [lib/libosg.so.2.3.3] Error 1 ... It seems that there is a problem with the arguments for linking (missing blank between -l and -Wl?) but I cannot find where this problem is located. Anyone around who knows what to do? 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 2008. 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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 -- # ## ## 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 2008. 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] FGCOM: how to go on?
Hi *, I am thinking about the next steps for fgcom. Jesper sent a patch for openal support and Tat made a patch for MacOSX (commited in the morning). Both are based on iaxclient (or iaxc) version 1. There is a nearly stable iaxc version 2 available which has some advantages (for VoIP, not necessarily for the usage with FG). The build system is now based on autotools which makes it complexer for me (I have no idea about autotools). But for further features it maybe not bad to use iaxc version 2 as a base for fgcom. However the current patches must be ported. My next ideas (intercom, noisy radio sound) for fgcom need changes at iaxc. So the big question is: Use iaxc v1 or iaxc v2? What do you think? 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 2008. 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
