Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
On 20 Oct 2008, at 10:06, Vladimir Karmishin wrote: I'm trying to compile Flightgear from CVS at OSX 10.5 systems. It seems the 10.5 lacks of alut.h header. After a little google-ing, I found that Apple removed that haader from leopard (Thanks, Apple!). Through, I'd found freealut implementation at OpenAL site. It compiles well, but at the linking stage - I receive a bunch of linking errors (listed at the end of this post). If someone had such exeprience with freealut on OSX - could give me a hand getting freealut to work ? Also, it seems that ALUT support is being deprecated at more and more systems. Is it a good idea, to rewrite Simgear sound classes w/o ALUT ? Being a bit upset about ALUT issues I started rewriting them yesterday, but who knows, maybe someone else is already doing this. :-) Removing ALUT would be a pain. I have one fix - I used the freealut sources to make a custom ALUT.framework, which works pretty well. I have to make some extra Simgear hacks to look for alut.h in ALUT/ alut.h instead of OpenAL/alut.h, however. Tat (who builds the macflightgear.org releases) uses a different solution - he just replaces the alut.h in his OpenAL framework with the alut.h from the freealut distribution. Both ways work, and neither has any particular advantage or disadvantage over the other. I can send you my framework and simgear diffs if you like, and you can try Tat's approach yourself straight away (I think) - since you have already grabbed the freealut sources. And yes, it's all a bit of a mess. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] livery - generic overlay
It's probably not well known that livery files (or other overlay files) have no defined structure. They are just XML files that are copied (laid) over the property tree on request. What you put in there, and where, is entirely your business. It doesn't have to do with liveries and textures at all. Take this example: Overlay file (in $FG_ROOT/Airports/Places/): ?xml version=1.0? PropertyList sim presets nameVienna City/name latitude-deg48.2402400/latitude-deg longitude-deg16.4106300/longitude-deg /presets /sim /PropertyList Nasal: gui.teleport_dialog = gui.OverlaySelector.new( Teleport to, # dialog title Airports/Places, # directory with overlay XML files sim/presets/name, # where the name is in those files nil, # no sorting property (- sort by name) nil, # no MP property (- no MP transmission) func fgcommand(presets-commit)); # what to do if new entry was chosen Binding: gui.teleport_dialog.open(); And if you now click entry Vienna City, you'll immediately get telported there. BTW: menu bindings should always use the open() method, keys always the toggle() method. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG joystick support limitations / absorbing PLIB
On 20 Oct 2008, at 10:18, Melchior FRANZ wrote: AFAIK that's not an option ATM. osgWidget is very new and was committed only a few weeks ago. It still only offers basic widgets, like plain buttons, text, menu, (tabbed) dialogs. Buttons are only colored rectangles, with no 3D appearance etc. I haven't seen anything advanced like comboboxes, list widgets, checkboxes etc. I think it will take another few months until we can seriously consider switching. But then a migration might not even be that much work. I knew it was 'new', didn't realise it was quite that basic. Definitely best to wait until it matures some more. As you say, once it provides all (or nearly all) of the required widgets then hopefully migration will not be too difficult. I also realised there are probably some other pieces of the code that still rely on sg or ssg types or functions, I guess Tim has more of an idea what those might be. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG joystick support limitations / absorbing PLIB
* James Turner -- Monday 20 October 2008: Anyone care to speculate on how much work it would be to migrate from pu to osgWidget? AFAIK that's not an option ATM. osgWidget is very new and was committed only a few weeks ago. It still only offers basic widgets, like plain buttons, text, menu, (tabbed) dialogs. Buttons are only colored rectangles, with no 3D appearance etc. I haven't seen anything advanced like comboboxes, list widgets, checkboxes etc. I think it will take another few months until we can seriously consider switching. But then a migration might not even be that much work. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG joystick support limitations / absorbing PLIB
* James Turner -- Monday 20 October 2008: I also realised there are probably some other pieces of the code that still rely on sg or ssg types or functions, - gui - (non-gui) fonts (i.e. texture fonts on instruments etc.) - joystick - networking and whatever they depend on. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG joystick support limitations / absorbing PLIB
* Melchior FRANZ -- Monday 20 October 2008: - (non-gui) fonts (i.e. texture fonts on instruments etc.) Whoops, no. That's already converted to OSG. Only non-gui fonts like the frame-rate counter and the ATC/multiplayer messages are concerned. But those aren't actually non-gui, they are just on fully transparent dialogs. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
Hi James ! Thank you for fast and informative answer. I guess, rewriting of wav file handling can be only difficult thing in removing ALUT away from FG. In fact, there only 4 ALUT functions FG uses. Initializing, Destroying and opening-closing streams. The implementation of first two is a piece of cake, I've implemented them as well. The second two - are bit more difficult to code, but there's a nice library, called libsndfile, allowing working with several sound file formats transparently. Right now I'm trying to remove ALUT (well, in fact i'm impementing some kind of #ifdef NO_ALUT code, so ALUT still can be used) from FG, and as far as I finished - I'll post here a patch. As I see around - the more and more of projects are moving away from ALUT, and probally FG has to do it some time. So, why not to start movement process now :-) On Oct 20, 2008, at 11:44 AM, James Turner wrote: On 20 Oct 2008, at 10:06, Vladimir Karmishin wrote: I'm trying to compile Flightgear from CVS at OSX 10.5 systems. It seems the 10.5 lacks of alut.h header. After a little google- ing, I found that Apple removed that haader from leopard (Thanks, Apple!). Through, I'd found freealut implementation at OpenAL site. It compiles well, but at the linking stage - I receive a bunch of linking errors (listed at the end of this post). If someone had such exeprience with freealut on OSX - could give me a hand getting freealut to work ? Also, it seems that ALUT support is being deprecated at more and more systems. Is it a good idea, to rewrite Simgear sound classes w/o ALUT ? Being a bit upset about ALUT issues I started rewriting them yesterday, but who knows, maybe someone else is already doing this. :-) Removing ALUT would be a pain. I have one fix - I used the freealut sources to make a custom ALUT.framework, which works pretty well. I have to make some extra Simgear hacks to look for alut.h in ALUT/ alut.h instead of OpenAL/alut.h, however. Tat (who builds the macflightgear.org releases) uses a different solution - he just replaces the alut.h in his OpenAL framework with the alut.h from the freealut distribution. Both ways work, and neither has any particular advantage or disadvantage over the other. I can send you my framework and simgear diffs if you like, and you can try Tat's approach yourself straight away (I think) - since you have already grabbed the freealut sources. And yes, it's all a bit of a mess. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG joystick support limitations / absorbing PLIB
On 18 Oct 2008, at 19:06, AJ MacLeod wrote: Opinions on that? It seems unfortunate, to say the least, that we are unable to support widely available good quality controller hardware because of our reliance on apparently dead projects... I wondered about this myself - the problem as I see it is that we're still using pu for the widgets, which means we need ssg, which means we need sg. I think we use the net layer as well, though that's a pretty thin layer over BSD sockets. So, at the moment, doing this means bringing in maybe 75% of PLIB, which seems counter-productive. It should be fine to move the Joystick module over now, though, and just drop / migrate other pieces incrementally. Anyone care to speculate on how much work it would be to migrate from pu to osgWidget? Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
On 20 Oct 2008, at 13:06, Vladimir Karmishin wrote: Thank you for fast and informative answer. I guess, rewriting of wav file handling can be only difficult thing in removing ALUT away from FG. In fact, there only 4 ALUT functions FG uses. Initializing, Destroying and opening-closing streams. The implementation of first two is a piece of cake, I've implemented them as well. The second two - are bit more difficult to code, but there's a nice library, called libsndfile, allowing working with several sound file formats transparently. Well, that's the thing - changing an ALUT dependency for something else, such as libsndfile, seems silly to me. If we're going to go down the alut removal path, let's instead find / write the smallest / simplest wav reader we can. For non-compressed .wavs, that's *extremely* simple, I've done it before. Basically a fixed size header and then the samples array. I've no idea which of the various compressions and encodings the .wavs in CVS use, but in the real-world, 99% of WAVs use one of a few standard schemes, so I'd be very wary of incorporating something as 'heavy' as libsndfile. If someone contributes an 'unusual' .wav, converting it to one of the more standard encodings is trivial. Just my personal opinion, of course. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG joystick support limitations / absorbing PLIB
James Turner wrote: On 20 Oct 2008, at 10:18, Melchior FRANZ wrote: AFAIK that's not an option ATM. osgWidget is very new and was committed only a few weeks ago. It still only offers basic widgets, like plain buttons, text, menu, (tabbed) dialogs. Buttons are only colored rectangles, with no 3D appearance etc. I haven't seen anything advanced like comboboxes, list widgets, checkboxes etc. I think it will take another few months until we can seriously consider switching. But then a migration might not even be that much work. I knew it was 'new', didn't realise it was quite that basic. Definitely best to wait until it matures some more. As you say, once it provides all (or nearly all) of the required widgets then hopefully migration will not be too difficult. I also realised there are probably some other pieces of the code that still rely on sg or ssg types or functions, I guess Tim has more of an PUI, the plib widget code, doesn't use the plib sg or ssg graphics stuff, except for a couple of type definitions. It would be a fine plan to suck PUI into FlightGear and make it play nicely with OSG. I don't propose to replace all the OpenGL code with OSG constructs, but using and setting the OSG state in a predictable way would eliminate the need for hacks and would make the GUI usable on more than one screen. I think osgWidget will take a while to mature. AFIAK things we take for granted like text field entry don't work at all; it's hard to get that kind of thing right. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG joystick support limitations / absorbing PLIB
On 20 Oct 2008, at 14:26, Tim Moore wrote: PUI, the plib widget code, doesn't use the plib sg or ssg graphics stuff, except for a couple of type definitions. It would be a fine plan to suck PUI into FlightGear and make it play nicely with OSG. Good to know - I'd assumed PUI was built on the SSG layers, precluding this. Seems strange to me, but it's beneficial now, so I won't complain. I don't propose to replace all the OpenGL code with OSG constructs, but using and setting the OSG state in a predictable way would eliminate the need for hacks and would make the GUI usable on more than one screen. Agreed, that sounds like a very sensible approach, and hopefully not overly complex. I think osgWidget will take a while to mature. AFIAK things we take for granted like text field entry don't work at all; it's hard to get that kind of thing right. Yes, and with a OSG native PUI, there's no need to rush such a change. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
Vladimir Karmishin wrote: As I see around - the more and more of projects are moving away from ALUT, and probally FG has to do it some time. So, why not to start movement process now :-) I find it rather annoying to have to move away from ALUT just because Apple can't play nice. Bad for them, let them straighten it out if they don't obey the the specs. I vote against this. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
* Erik Hofman -- Monday 20 October 2008: I find it rather annoying to have to move away from ALUT just because Apple can't play nice. Bad for them, let them straighten it out if they don't obey the the specs. I vote against this. The problem seems to be that the original (Creative) OpenAL seems to be dead. Development has stalled in a buggy state. Debian has forked OpenAL under name OpenAL Soft, but apparently not alut, which is a bit strange. No idea how well old alut works with new openal. So, is alut now unmaintained, and dead-ish? http://kcat.strangesoft.net/openal.html m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
Melchior FRANZ wrote: * Erik Hofman -- Monday 20 October 2008: I find it rather annoying to have to move away from ALUT just because Apple can't play nice. Bad for them, let them straighten it out if they don't obey the the specs. I vote against this. The problem seems to be that the original (Creative) OpenAL seems to be dead. Development has stalled in a buggy state. Debian has forked OpenAL under name OpenAL Soft, but apparently not alut, which is a bit strange. No idea how well old alut works with new openal. So, is alut now unmaintained, and dead-ish? http://kcat.strangesoft.net/openal.html Freealut was removed from OpenAL before OpenAL version 1.1 and is designed to work with every other implementation of OpenAL. OpenAL itself was never developed bij Creative but by Loki, which was later bought by Creative. But the Loki implementation is still available since it is licensed under the terms of the LGPL. The OpenAL-Soft implementation is based on an old version of OpenAL developed bij Creative but never finished. This version too is LGPL and even seems to work with Creative's binary drivers for Windows. I use freealut myself using my own implementation of OpenAL. The main problem is that Apple never removed the alut functions from their OpenAL library causing linking conflicts wehn linking both freealut and OpenAL. \ Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
On 20 Oct 2008, at 15:30, Erik Hofman wrote: The main problem is that Apple never removed the alut functions from their OpenAL library causing linking conflicts wehn linking both freealut and OpenAL. Well, to be fair that's to preserve binary compatibility. I work around that trivially be ensuring -framework ALUT comes before - framework OpenAL on my link command. But, the whole situation is a bit of a mess. Apple aren't helping, but they aren't actively trying to be awkward (is my perception) - it's just very unclear what the best course of action for them (or Debian, or anyone else) is with OpenAL. Ack. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
Eric, the only problem with ALUT - it is not a part of OpenAL, and it doesn't have any strict specs. So nobody can guarantee it's reliability. In fact, I have to agree with Melchior FRANZ, about the whole OpenAL subsystem. Since Creative abadoned the development - it's completely dead. FMOD seems to be a good alternative to OpenAL, but it has some legal issues if I remember right. On Mon, Oct 20, 2008 at 3:45 PM, Erik Hofman [EMAIL PROTECTED] wrote: Vladimir Karmishin wrote: As I see around - the more and more of projects are moving away from ALUT, and probally FG has to do it some time. So, why not to start movement process now :-) I find it rather annoying to have to move away from ALUT just because Apple can't play nice. Bad for them, let them straighten it out if they don't obey the the specs. I vote against this. Erik -- Vladimir Karmishin ASTRA Development Inc. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
Vladimir Karmisin wrote: Eric, the only problem with ALUT - it is not a part of OpenAL, and it doesn't have any strict specs. So nobody can guarantee it's reliability. In fact, I have to agree with Melchior FRANZ, about the whole OpenAL subsystem. Since Creative abadoned the development - it's completely dead. Creative didn't abandon OpenAL en OpenAL isn't dead. Loki went belly up leaving things in a bit of a bad shape for Linux. OpenAL-Soft partly solves that problem these days. Free ALUT solves the other half of that problem and it *does* have a formal spec. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
James Turner wrote: On 20 Oct 2008, at 15:30, Erik Hofman wrote: The main problem is that Apple never removed the alut functions from their OpenAL library causing linking conflicts wehn linking both freealut and OpenAL. Well, to be fair that's to preserve binary compatibility. I work around that trivially be ensuring -framework ALUT comes before - framework OpenAL on my link command. They only have to provide binary compatibility for applications that use OpenAL 1.0. Applications that use OpenAL 1.1 should have linked against a different library that doesn't contain the ALUT functions and there would have been no problem. But instead Apple combines OpenAL version 1.0 and OpenAL evrsion 1.1 in one library and decided to use include/OpenAL instead of include/AL I see this solely as a problem they created themselves. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
James, if it doesn't mean problem for you, could You send me your framework and SG patches ? About libsnd - Yes, you may be right in case of libsndfile. I've coded a simple WAV reader, which does nothig but read uncompressed wav file and fill out OpenAL buffer by PCM data. The whole code is about 40 lines long. On Mon, Oct 20, 2008 at 11:44 AM, James Turner [EMAIL PROTECTED] wrote: On 20 Oct 2008, at 10:06, Vladimir Karmishin wrote: I'm trying to compile Flightgear from CVS at OSX 10.5 systems. It seems the 10.5 lacks of alut.h header. After a little google-ing, I found that Apple removed that haader from leopard (Thanks, Apple!). Through, I'd found freealut implementation at OpenAL site. It compiles well, but at the linking stage - I receive a bunch of linking errors (listed at the end of this post). If someone had such exeprience with freealut on OSX - could give me a hand getting freealut to work ? Also, it seems that ALUT support is being deprecated at more and more systems. Is it a good idea, to rewrite Simgear sound classes w/o ALUT ? Being a bit upset about ALUT issues I started rewriting them yesterday, but who knows, maybe someone else is already doing this. :-) Removing ALUT would be a pain. I have one fix - I used the freealut sources to make a custom ALUT.framework, which works pretty well. I have to make some extra Simgear hacks to look for alut.h in ALUT/ alut.h instead of OpenAL/alut.h, however. Tat (who builds the macflightgear.org releases) uses a different solution - he just replaces the alut.h in his OpenAL framework with the alut.h from the freealut distribution. Both ways work, and neither has any particular advantage or disadvantage over the other. I can send you my framework and simgear diffs if you like, and you can try Tat's approach yourself straight away (I think) - since you have already grabbed the freealut sources. And yes, it's all a bit of a mess. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Vladimir Karmishin ASTRA Development Inc. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
On 20 Oct 2008, at 16:02, Vladimir Karmisin wrote: James, if it doesn't mean problem for you, could You send me your framework and SG patches ? Yep, I'll get them sent when I have a spare moment (maybe tomorrow, however) About libsnd - Yes, you may be right in case of libsndfile. I've coded a simple WAV reader, which does nothig but read uncompressed wav file and fill out OpenAL buffer by PCM data. The whole code is about 40 lines long. Right. It would be interesting to do a find . -name *.wav on data/ and see what compression the current WAVs are using. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Rendering option /Precipitation
Hello, I can't avoid precipitation with the Rendering option menu , is it just me ? Cheers - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
Vladimir Karmisin wrote: James, if it doesn't mean problem for you, could You send me your framework and SG patches ? About libsnd - Yes, you may be right in case of libsndfile. I've coded a simple WAV reader, which does nothig but read uncompressed wav file and fill out OpenAL buffer by PCM data. The whole code is about 40 lines long. If you want any chance to get it included into SimGear/FlightGear you must make sure it is independent of endiannes and that it can work with 32-bit and 64-bit systems. 40 lines of code seem very little for that.. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
On Oct 20, 2008, at 6:26 PM, Erik Hofman wrote: Vladimir Karmisin wrote: James, if it doesn't mean problem for you, could You send me your framework and SG patches ? About libsnd - Yes, you may be right in case of libsndfile. I've coded a simple WAV reader, which does nothig but read uncompressed wav file and fill out OpenAL buffer by PCM data. The whole code is about 40 lines long. If you want any chance to get it included into SimGear/FlightGear you must make sure it is independent of endiannes and that it can work with 32-bit and 64-bit systems. 40 lines of code seem very little for that.. Erik, it's just a simple startup code right now. Written only for test purposes for myself. Of course, if I feel I want to get it included in FG I'll polish it and take a care of endiannes. But thanks you for the care :-) Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
Hi, Here's my old patch to include local alut.h into SimGear. http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk/patches/SimGear-0.3-cvs-20061203-MacOSX.diff?revision=168view=markup This will place alut.h inside SimGear. (Not inside OpenAL.framework) You can modify this patch to include your ALUT header. I also want to add some tips on building flightgear on macs. 1) avoid using -O2, -O3, or -O3 with gcc 4.0 (comes with Xcode 3.1.x). It will cause flightgear segfault. 2) modify OpenAL/alc.h (and alut.h) for avoiding compiler error when using gcc 4.2. The key is changing both ALvoid and ALCvoid to void if it is the only argument in a prototype declaration. I don't know what is the best to avoid this problem, but for a binary package, I don't want to include redundant framework. That's why I locally have alut.h instead of building ALUT.framework. About ALUT alternatives, I really want to have one since it will save many fg developers on Macs. I don't know what is better, though. Best, - Tatsuhiro Nishioka On Oct 20, 2008, at 6:44 PM, James Turner [EMAIL PROTECTED] wrote: Removing ALUT would be a pain. I have one fix - I used the freealut sources to make a custom ALUT.framework, which works pretty well. I have to make some extra Simgear hacks to look for alut.h in ALUT/ alut.h instead of OpenAL/alut.h, however. Tat (who builds the macflightgear.org releases) uses a different solution - he just replaces the alut.h in his OpenAL framework with the alut.h from the freealut distribution. Both ways work, and neither has any particular advantage or disadvantage over the other. I can send you my framework and simgear diffs if you like, and you can try Tat's approach yourself straight away (I think) - since you have already grabbed the freealut sources. And yes, it's all a bit of a mess. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
Vladimir Karmishin wrote: Erik, it's just a simple startup code right now. Written only for test purposes for myself. Of course, if I feel I want to get it included in FG I'll polish it and take a care of endiannes. But thanks you for the care :-) Actually I do have code laying around that does exactly that but it can only read so called canonical wave files, meaning the layout should be exactly like that otherwise it will fail (meybe even coredump). I find that much too limited for a project like FlightGear, hence my vote against abandoning ALUT (which I know works well, actually it even contains code from me). Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering option /Precipitation
On lundi 20 octobre 2008, robin424 wrote: Hello, I can't avoid precipitation with the Rendering option menu , is it just me ? Cheers And modifying any parameters within preference.xml about precipitation don't change anything Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear CVS, OSX Leopard 10.5.5 and freealut.
On Oct 20, 2008, at 7:09 PM, Erik Hofman wrote: Actually I do have code laying around that does exactly that but it can only read so called canonical wave files, meaning the layout should be exactly like that otherwise it will fail (meybe even coredump). I find that much too limited for a project like FlightGear, hence my vote against abandoning ALUT (which I know works well, actually it even contains code from me). Developing a code which can work with any type of wav-s, of course will take much longer than 40 lines. Even if we forget about that fact, that wav is just a container, that can contain virtually anything. Implementing a proper WAV handler can be a real headache, it's true. Right now - as I see, ALUT is used only due the WAVE reading purposes, because initialization-destruction of OpenAL is really simple and can be implemented in SimGear code directly. It will take several lines longer than now. In fact - just abadoning ALUT will cause more troubles than advantages, so I'm planning to write an alternative and let user decide which approach to use simply by ./configure -ing with key...let's say --without-alut. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS CitationX and Bravo segfault at EGPF
On Sun, 2008-10-19 at 12:27 +0100, James Turner wrote: On 18 Oct 2008, at 22:30, Alasdair Campbell wrote: I wonder if anyone can confirm the following strange behaviour or give me me a hint as to where to start looking? If I start up either the CitatationX or the Bravo at EGPF (my local airport), on selecting Autostart, fgfs gives me a segfault. Any other airport, everything works perfectly. I am using a fresh checkout of today's Simgear, FG source and data. You don't need the UK scenery to demonstrate this fault. dominatrix:~fgfs --aircraft=CitationX --airport=EGPF FGMultiplayMgr - No receiver port, Multiplayermode disabled Electrical System ... ok Flight Director ...Check Primus 1000 systems ... check Segmentation fault Yep, I'm getting this as well at EGPF, with either Citation. It's something to do with my FGPositioned changes, and *seems* to be related to the KLN89b / DCLGPS code - except as far as I can tell, neither Citation uses the KLN89b - in fact, the only aircraft that does is one of the c172 variants. I sort of assume it must happen at other airports, but since I often fly locally around that area, EGPF is always where i get it. Oh, it also crashes if you arrive at EGPF from outside - I did a flight around the western isles and down over Loch Lomond, and as I was manoeuvring to intercept the localiser of one of the runways, got the exact same crash. So it's something pretty weird. If it really is *only* EGPF that has this issue, that's even more weird, of course. Anyway, I am pretty sure this is my fault, I will dig into it tonight. James The problem actually lies in Instrumentation/mk_viii.cxx in MK_VIII::TCFHandler::update_runway, recently patched by yourself. (gdb backtrace enclosed) I am unsufficently clued up in c++ to figure out what this code is trying to do, and I would be delighted if you could inform me why EGPF breaks this code. Kind regards, Alasdair - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel dominatrix:~gdb fgfs GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu... (gdb) run Starting program: /usr/local/bin/fgfs [Thread debugging using libthread_db enabled] [New Thread 0xb62146e0 (LWP 10229)] [New Thread 0xb2df0b90 (LWP 10232)] Error: connect() failed in make_client_socket() SG_IO_OUT socket creation failed VOICE: no connection to `localhost:1314' [New Thread 0xb25efb90 (LWP 10233)] [New Thread 0xb1bcdb90 (LWP 10234)] [New Thread 0xb13ccb90 (LWP 10235)] Electrical System ... ok Flight Director ...Check Primus 1000 systems ... check Chat [*FGMS*] Welcome to pigeond.net Chat [*FGMS*] using protocol version v1.1This server is tracked. Chat [*FGMS*] alcam is now online, using Chat [*FGMS*] Aircraft/CitationX/Models/Citation-X.xml Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb62146e0 (LWP 10229)] 0x083e0115 in MK_VIII::TCFHandler::update_runway (this=0xe94d95c) at mk_viii.cxx:4545 4545 runway.center.latitude = _runway-latitude(); (gdb) backtrace #0 0x083e0115 in MK_VIII::TCFHandler::update_runway (this=0xe94d95c) at mk_viii.cxx:4545 #1 0x083e02f9 in MK_VIII::TCFHandler::update (this=0xe94d95c) at mk_viii.cxx:4808 #2 0x083e8c16 in MK_VIII::update (this=0xe94d218, dt=0.01) at mk_viii.cxx:4954 #3 0x085ca0a9 in SGSubsystemGroup::Member::update (this=0xef408d0, delta_time_sec=0.01) at subsystem_mgr.cxx:309 #4 0x085cbdfe in SGSubsystemGroup::update (this=0xef7fe08, delta_time_sec=0.01) at subsystem_mgr.cxx:162 #5 0x085ca0a9 in SGSubsystemGroup::Member::update (this=0xefb2488, delta_time_sec=0.01) at subsystem_mgr.cxx:309 #6 0x085cbdfe in SGSubsystemGroup::update (this=0x8ee66dc, delta_time_sec=0.01) at subsystem_mgr.cxx:162 #7 0x08069d60 in fgMainLoop () at main.cxx:491 #8 0x080a6e42 in flightgear::FGManipulator::handle (this=0x8ee5470, [EMAIL PROTECTED], [EMAIL PROTECTED]) at FGManipulator.cxx:183 #9 0xb773ea5d in osgViewer::Viewer::eventTraversal () from /usr/local/lib/libosgViewer.so.47 #10 0xb77488b3 in
[Flightgear-devel] OV-10 adf needle
here's a patch concerning the OV-10 aircraft, adf needdle is rotated by the heading fist, wich is false, the adf bearing rotation is enough jano Index: ./Aircraft/OV10/Models/USAFE/Instruments/BDHI/HI-f8e.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/OV10/Models/USAFE/Instruments/BDHI/HI-f8e.xml,v retrieving revision 1.1 diff -u -r1.1 HI-f8e.xml --- ./Aircraft/OV10/Models/USAFE/Instruments/BDHI/HI-f8e.xml 28 Feb 2007 22:25:48 - 1.1 +++ ./Aircraft/OV10/Models/USAFE/Instruments/BDHI/HI-f8e.xml 19 Oct 2008 11:58:38 - @@ -309,22 +309,6 @@ animation typerotate/type object-nameAiguille1-Adf/object-name - property/orientation/heading-magnetic-deg/property - center - x-m0/x-m - y-m0/y-m - z-m0/z-m - /center - axis - x1/x - y0/y - z0/z - /axis - /animation - - animation - typerotate/type - object-nameAiguille1-Adf/object-name property/instrumentation/adf/indicated-bearing-deg/property factor1/factor center - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS CitationX and Bravo segfault at EGPF
On Mon, 2008-10-20 at 22:20 +0100, Alasdair Campbell wrote: On Sun, 2008-10-19 at 12:27 +0100, James Turner wrote: On 18 Oct 2008, at 22:30, Alasdair Campbell wrote: I wonder if anyone can confirm the following strange behaviour or give me me a hint as to where to start looking? If I start up either the CitatationX or the Bravo at EGPF (my local airport), on selecting Autostart, fgfs gives me a segfault. Any other airport, everything works perfectly. I am using a fresh checkout of today's Simgear, FG source and data. You don't need the UK scenery to demonstrate this fault. dominatrix:~fgfs --aircraft=CitationX --airport=EGPF FGMultiplayMgr - No receiver port, Multiplayermode disabled Electrical System ... ok Flight Director ...Check Primus 1000 systems ... check Segmentation fault Yep, I'm getting this as well at EGPF, with either Citation. It's something to do with my FGPositioned changes, and *seems* to be related to the KLN89b / DCLGPS code - except as far as I can tell, neither Citation uses the KLN89b - in fact, the only aircraft that does is one of the c172 variants. I sort of assume it must happen at other airports, but since I often fly locally around that area, EGPF is always where i get it. Oh, it also crashes if you arrive at EGPF from outside - I did a flight around the western isles and down over Loch Lomond, and as I was manoeuvring to intercept the localiser of one of the runways, got the exact same crash. So it's something pretty weird. If it really is *only* EGPF that has this issue, that's even more weird, of course. Anyway, I am pretty sure this is my fault, I will dig into it tonight. James The problem actually lies in Instrumentation/mk_viii.cxx in MK_VIII::TCFHandler::update_runway, recently patched by yourself. (gdb backtrace enclosed) I am unsufficently clued up in c++ to figure out what this code is trying to do, and I would be delighted if you could inform me why EGPF breaks this code. Kind regards, Alasdair I added a line of code to show me which was the closest airport detected (patch attached) and was amused to notice the following: dominatrix:~fgfs --aircraft=CitationX --airport=EGPF Error: connect() failed in make_client_socket() SG_IO_OUT socket creation failed VOICE: no connection to `localhost:1314' Electrical System ... ok Flight Director ...Check Primus 1000 systems ... check Chat [*FGMS*] alcam is now online, using Chat [*FGMS*] this is version v0.9.11 (LazyRelay rev 1.14) ***ALI **closest airport is FSPP PRASLIN Segmentation fault dominatrix:~ Had I realized that the Seychelles were less than 15 nm from Glasgow, I would have revisited many times. Regards, Alasdair --- mk_viii.cxx 2008-10-21 00:07:08.0 +0100 +++ mk_viii_mine.cxx 2008-10-20 23:49:43.0 +0100 @@ -71,7 +71,7 @@ #include simgear/misc/sg_path.hxx #include simgear/sound/soundmgr_openal.hxx #include simgear/structure/exception.hxx - +#include iostream using std::string; #include Airports/runways.hxx @@ -4536,7 +4536,7 @@ 0.5, filter); if (!airport) return; - + cout***ALI **closest airport is airport-getId() airport-getName()endl; has_runway = true; FGRunway* _runway; - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS CitationX and Bravo segfault at EGPF
On Tue, 2008-10-21 at 00:31 +0100, Alasdair Campbell wrote: On Mon, 2008-10-20 at 22:20 +0100, Alasdair Campbell wrote: On Sun, 2008-10-19 at 12:27 +0100, James Turner wrote: On 18 Oct 2008, at 22:30, Alasdair Campbell wrote: I wonder if anyone can confirm the following strange behaviour or give me me a hint as to where to start looking? If I start up either the CitatationX or the Bravo at EGPF (my local airport), on selecting Autostart, fgfs gives me a segfault. Any other airport, everything works perfectly. I am using a fresh checkout of today's Simgear, FG source and data. You don't need the UK scenery to demonstrate this fault. dominatrix:~fgfs --aircraft=CitationX --airport=EGPF FGMultiplayMgr - No receiver port, Multiplayermode disabled Electrical System ... ok Flight Director ...Check Primus 1000 systems ... check Segmentation fault Yep, I'm getting this as well at EGPF, with either Citation. It's something to do with my FGPositioned changes, and *seems* to be related to the KLN89b / DCLGPS code - except as far as I can tell, neither Citation uses the KLN89b - in fact, the only aircraft that does is one of the c172 variants. I sort of assume it must happen at other airports, but since I often fly locally around that area, EGPF is always where i get it. Oh, it also crashes if you arrive at EGPF from outside - I did a flight around the western isles and down over Loch Lomond, and as I was manoeuvring to intercept the localiser of one of the runways, got the exact same crash. So it's something pretty weird. If it really is *only* EGPF that has this issue, that's even more weird, of course. Anyway, I am pretty sure this is my fault, I will dig into it tonight. James The problem actually lies in Instrumentation/mk_viii.cxx in MK_VIII::TCFHandler::update_runway, recently patched by yourself. (gdb backtrace enclosed) I am unsufficently clued up in c++ to figure out what this code is trying to do, and I would be delighted if you could inform me why EGPF breaks this code. Kind regards, Alasdair I added a line of code to show me which was the closest airport detected (patch attached) and was amused to notice the following: dominatrix:~fgfs --aircraft=CitationX --airport=EGPF Error: connect() failed in make_client_socket() SG_IO_OUT socket creation failed VOICE: no connection to `localhost:1314' Electrical System ... ok Flight Director ...Check Primus 1000 systems ... check Chat [*FGMS*] alcam is now online, using Chat [*FGMS*] this is version v0.9.11 (LazyRelay rev 1.14) ***ALI **closest airport is FSPP PRASLIN Segmentation fault dominatrix:~ Had I realized that the Seychelles were less than 15 nm from Glasgow, I would have revisited many times. Regards, Alasdair I have now established why this problem appeared so weird. In Instrumentation/mk_viii.cxx at line 4534 you've got latitude and longitude transposed in const FGAirport *airport = globals-get_airports()-search( mk_data(gps_latitude).get(), mk_data(gps_longitude).get(), 0.5, filter); Correcting this error will will cause the Citations to crash at line 4545 at ALL airports which is kind of saner. As you suggested, the problem seems to lie in the longitude(), latitude() etc defined in positioned.hxx I have beavered away in the midnight oil to fix, but am too hampered by poor c++ skills. Regards, Alasdair - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
