Re: [Flightgear-devel] Compiling Flightgear 0.9.8 on Mac OS X 10.4.2
Hi Markus, Markus Morawitz wrote: Hello, I tried to compile Flightgear on a G4 running Mac OS X 10.4.2. There were several compilation errors which I could overcome by changing several source files in the packages: FlightGear-0.9.8 SimGear-0.3.8 plib-1.8.4 In detail, the list of files with a short change description: I have changed all entries that weren't already changed and were still present. It would be nice to make these changed to the CVS version of FlightGear since the clouds3d directory has just recently be removed from out build tree. plib-1.8.4/src/js/jsMacOSX.cxx line 278: static has to be deleted You will have to sent this to the plib developers list since we can't change plib CVS. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Overhauling the networking code(was:Multiplayer crashes with unknown aircrafts, any solution?)
Mathias Fröhlich > Hi, > > On Sonntag 17 Juli 2005 10:16, Vivian Meazza wrote: > > Before we do any rework of the MP code, it works as is in 0.9.8 (with > some > > bugs), but it is fundamentally broken in CVS. In cvs the received > aircraft > > are displayed close to the observer, rather than in their proper > locations. > > It works OK in 0.9.8. Melchior suggested this was something to do with > one > > of your recent updates, but I haven't rolled back to establish if this > is > > the case. > > The jitter removal patch was the cause for that. > But to be honest, that current multiplayer protocol cannot really work. > It transmits only offsets to the tile center without the information on > which > tile it is. > This was more or less sufficient for the case we had the scenery center at > the > tile center. But flying across tile bondaries was still broken ... > > I have now included a patch to the multiplyer protocoll which does: > > 1. place the 3d model into the scenery using a placement transform which > can > dynamically change its scenry center. > 2. Transmits unique position and orientation data for the 3d model. > 3. Thus breaks protocol compatibility. > :-/ > > Since the fg_server only forwards the network packets without looking into > them, this will still work with that code. > But the position data sent by a flightgear release version cannot be > understood by the current version. The same holds for the other way. > > Opinions? > > Given that it will make that usable in some way I will vote for applying. > > Anyway, this protocol is very error prone since it neither cares for > alignment > nor for endianess. I don't know of it still works for x86_64, don't talk > about the sgi's in Erik's zoo ... > :) This patch does not work for Cygwin. I'm not sure if Multiplayer ever worked under Cygwin. Norman Vine did a bit of quick diagnosis last night, and came up with a cause and a fix. Apparently Linux uses 4 bytes while Cygwin uses 8 as standard. I attach Norman's diff against cvs/head. Btw, if there any other Cygwin users still out there - I've just updated my copy of Cygwin. The latest version gives a worthwhile improvement in both file reading and in frame rate. Vivian mpmessages.diff Description: Binary data ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayer crashes with unknown aircrafts, any solution?)
Vivian Meazza wrote: >This patch does not work for Cygwin. I'm not sure if Multiplayer ever worked >under Cygwin. > > >Norman Vine did a bit of quick diagnosis last night, and came up with a >cause and a fix. Apparently Linux uses 4 bytes while Cygwin uses 8 as >standard. > > > Apperantly gcc under cygwin uses a different alignment for structs than gcc under linux (I don't know which gcc version is used under cygwin). At home I use gcc 3.3.6, and it reports: sizeof(T_MsgHdr) + sizeof (T_POSMSG) = 120 Under cygwin it reports: sizeof(T_MsgHdr) + sizeof (T_POSMSG) = 124 >I attach Norman's diff against cvs/head. > > Norman tried to get cygwin do the same alignment which other gcc do. That's this (commented out) _attribute_ thing for, but didn't succeed. So he made an ugly hack which let you use multiplayer-mode anyway. But this hack fixes symtoms, not the cause. I don't have the right anwser, either. We must check this out and improve the used structures and their alignment. greets, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30 airports
Le mardi 26 juillet 2005 à 23:13 +0200, Mathias Fröhlich a écrit :
> Hi,
>
> sorry for the late reaction.
> Turns out to be a bad interaction between jsbsims crash detection and my
> past initialization changes.
> The attached patch fixes this by moving crash detection out of the
> initialization phase of jsbsim.
>
> Erik,
> Can you apply that please to flightgears cvs.
> I will care for JSBsim's cvs.
>
> Thanks and sorry
>
Hello Mathias,
I don't understand why do you continu to develop on that wrong crash
detection.
It is a nonsense regarding the JSB undercarriage facilities.
it is a nonsense regarding the other old crash detection process
in
FGLGear.cpp line 507
Here's the code:
// Crash detection logic (really out-of-bounds detection)
if (compressLength > 500.0 ||
vForce.Magnitude() > 1.0 ||
vMoment.Magnitude() > 50.0 ||
SinkRate > 1.4666*30)
{
PutMessage("Crash Detected: Simulation FREEZE.");
Exec->Freeze();
}
The undercarriage definition is very flexible. It gives the facilities
to manage an aircraft customised crash animation with the help of a
nasal script.
If an improvement must be done it could be done on the old existing code
with specifics properties like that one which is coming from a Dave
mail.
0
11.0
5.0
20
20
1089.0
3.7
3.5
0.99
I fear, the user opinion is not useful for the development team.
I fear the user opinion is not taken in account.
Please tell me, by that way i will continu to subscribe or not.
Thanks
--
Gerard
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Tue, 2005-07-26 at 17:34, Erik Hofman wrote: > that's all [fgSunPositionGST] does, give an angle to display the pretty > colors > properly. > Doh! That's a silly way to do it (see below). > > Give me a bit longer to disentangle it all! I can't work on it right > > now, (I'm at work) but I can take a quick look at lunchtime, and do more > > this evening. > > I can imagine, I had trouble finding out what's going on also :-\ > Tell me about it! Here's a basic audit: The julian_date() routine is pretty much word for word the same as Johnson's original, but it's 'static' and only used by the GST() routine. The GST() routine is also word for word identical with Johnson's. It is 'static' and only used by fgSunPosition(). fgSunPosition() isn't used anywhere! So we could ditch all three of these routines immediately with no possible ill effect. FlightGear's 'ecliptic_to_equatorial()' routine is a modified version of Johnson's and it might be said that his copyright in it is no longer relevant. It is, after all just an implementation of the algorithm in Duffett-Smith's book (I've got a copy in front of me). The only novel thing is that my (first edition) copy of the book uses 'atan' and has to sort out the ambiguities caused by that afterwards, but Johnson's and FlightGear's version (sensibly) uses 'atan2()' to avoid the ambiguity in the first place. This is a pretty obvious implementation issue, but who thought of it? Johnson? Or is like that in the third edition of Duffett-Smith?. The 'ecliptic_to_equatorial()' routine gets used by fgSunPosition (not used) and fgSunPositionGST only. Both these routines are rewrites of Johnson's sun_position() routine, and are probably similar enough to be a problem. As stated at the start of the audit, we could lose 'fgSunPosition()' immediately since it isn't actually used anywhere. FlightGear's 'fgUpdateSunPos()' routine seems to have no obvious connection to Johnson's code, though it does call fgSunPositionGST(). I'm not convinced that FlightGear even wants to do this anyway. Surely it should have done a conversion from sun's equatorial coordinates (right ascension and declination) to horizon coordinates (altitude and azimuth) since, as Erik says above, all FlightGear wants to know is the bearing of the sun below the horizon so that it can get the dusk lighting correct! Altitude and azimuth would seem to be the ideal data for that. The only other call to 'fgSunPositionGST()' is in sunsolver.cxx and that's for finding sunrise or sunset time as mentioned before. Again, knowing solar alt/az from the location of the viewer would have been more useful I think. Looks like binning 'sunpos.cxx' will be relatively trivial. Still working on it though. Gotta be careful not to break some cunning interdependency... Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30 airports
Mathias Fröhlich wrote: Erik, Can you apply that please to flightgears cvs. I will care for JSBsim's cvs. Done. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayer crashes with unknown aircrafts, any solution?)
Vivian Meazza wrote: This patch does not work for Cygwin. I'm not sure if Multiplayer ever worked under Cygwin. Norman Vine did a bit of quick diagnosis last night, and came up with a cause and a fix. Apparently Linux uses 4 bytes while Cygwin uses 8 as standard. I attach Norman's diff against cvs/head. Which doesn't work for non gcc compilers (actually it probably won't work on the latest gcc compiler version either) ... Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
> FGLGear.cpp line 507
> Here's the code:
> // Crash detection logic (really out-of-bounds detection)
> if (compressLength > 500.0 ||
> vForce.Magnitude() > 1.0 ||
> vMoment.Magnitude() > 50.0 ||
> SinkRate > 1.4666*30)
> {
>PutMessage("Crash Detected: Simulation FREEZE.");
>Exec->Freeze();
> }
> The undercarriage definition is very flexible. It gives the facilities
> to manage an aircraft customised crash animation with the help of a
> nasal script.
> If an improvement must be done it could be done on the old existing code
> with specifics properties like that one which is coming from a Dave
> mail.
>
> 0
>11.0
>5.0
>20
>20
>1089.0
>3.7
>3.5
>0.99
>
The out-of-bounds detection logic was a development piece of code, really. That
can be removed if it is causing a problem.
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
Le mercredi 27 juillet 2005 à 07:05 -0500, Jon Berndt a écrit :
> > FGLGear.cpp line 507
> > Here's the code:
> > // Crash detection logic (really out-of-bounds detection)
> > if (compressLength > 500.0 ||
> > vForce.Magnitude() > 1.0 ||
> > vMoment.Magnitude() > 50.0 ||
> > SinkRate > 1.4666*30)
> > {
> >PutMessage("Crash Detected: Simulation FREEZE.");
> >Exec->Freeze();
> > }
> > The undercarriage definition is very flexible. It gives the facilities
> > to manage an aircraft customised crash animation with the help of a
> > nasal script.
> > If an improvement must be done it could be done on the old existing code
> > with specifics properties like that one which is coming from a Dave
> > mail.
> >
> > 0
> >11.0
> >5.0
> >20
> >20
> >1089.0
> >3.7
> >3.5
> >0.99
> >
>
> The out-of-bounds detection logic was a development piece of code, really.
> That can be removed if it is causing a problem.
>
> Jon
>
>
I did NOT ask for deleting that piece of code which is rather good (and
could be improved),
i only ask for to remove the new AGL test
^^
which delete the UNDERCARIAGE facilities.
Am i understandable ?
--
Gerard
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Overhauling the networking code(was:Multiplayercrashes with unknown aircrafts, any solution?)
Erik Hofman > Vivian Meazza wrote: > > > This patch does not work for Cygwin. I'm not sure if Multiplayer ever > worked > > under Cygwin. > > > > Norman Vine did a bit of quick diagnosis last night, and came up with a > > cause and a fix. Apparently Linux uses 4 bytes while Cygwin uses 8 as > > standard. > > > > I attach Norman's diff against cvs/head. > > Which doesn't work for non gcc compilers (actually it probably won't > work on the latest gcc compiler version either) ... > It's a quick and dirty hack. Oliver and Norman are working on a proper fix. It compiles on gcc 3.4.4-1. If Cygwin users want to use multiplayer, then this patch allows it. It certainly should not find its way into cvs. Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Wed, 2005-07-27 at 12:29, Steve Hosgood (that's me) wrote: > The julian_date() routine is pretty much word for word the same as > Johnson's original, but it's 'static' and only used by the GST() > routine. > > The GST() routine is also word for word identical with Johnson's. It is > 'static' and only used by fgSunPosition(). > > fgSunPosition() isn't used anywhere! So we could ditch all three of > these routines immediately with no possible ill effect. > Just tried it. Also removed the 'extern' reference to 'fgSunPosition()' in sunpos.hxx and it all compiles just fine as expected. Much the same thing applies to moonpos.cxx too. There's a 'julian_date()', 'GST()' and 'fgMoonPosition()' set of defunct routines in there which can be deleted with no ill effect. Remove the 'extern' reference to 'fgMoonPosition()' from moonpos.hxx too. Still working on the remaining issues. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Property Tree Catalog
Well, without the benefit of SimGear as a whole, I've crafted a [probably
non-optimal]
property tree cataloging function for use in JSBSim. Thought you might like to
see it:
//%%
struct PropertyCatalogStructure {
string base_string;
FGPropertyManager *node;
};
void FGFDMExec::BuildPropertyCatalog(struct PropertyCatalogStructure* pcs)
{
struct PropertyCatalogStructure* pcsNew = new struct PropertyCatalogStructure;
int node_idx = 0;
char int_buf[10];
for (int i=0; inode->nChildren(); i++) {
pcsNew->base_string = pcs->base_string + "/" +
pcs->node->getChild(i)->getName();
node_idx = pcs->node->getChild(i)->getIndex();
sprintf(int_buf, "[%d]", node_idx);
if (node_idx != 0) pcsNew->base_string += string(int_buf);
if (pcs->node->getChild(i)->nChildren() == 0) {
PropertyCatalog.push_back(pcsNew->base_string +
pcs->node->getChild(i)->getName());
} else {
pcsNew->node = (FGPropertyManager*)pcs->node->getChild(i);
BuildPropertyCatalog(pcsNew);
}
}
delete pcsNew;
}
//%%
It's called like this:
//%%
struct PropertyCatalogStructure masterPCS;
masterPCS.base_string = "";
masterPCS.node = (FGPropertyManager*)master;
BuildPropertyCatalog(&masterPCS);
cout << endl << "Registered properties: " << endl;
for (int i=0; ihttp://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Debian Installation
LeeE I am trying to install plib and I got errors, it seems to be "Mesa" that is not installed. cd plib-1.8.4/ ./configure . . . checking for IceConnectionNumber in -lICE... no checking for pthread_create in -lpthread... no checking for glNewList in -lGL... no checking for glNewList in -lMesaGL... no configure: error: could not find working GL library Wich package is missing? Regards, FS Quoting Lee Elliott <[EMAIL PROTECTED]>: > On Tuesday 26 Jul 2005 12:43, [EMAIL PROTECTED] wrote: > > Hi, > > > > I have been trying to install the FGFS on my PC but I am > > having problem to configure the DEBIAN packages on the proper > > order before I start the FGFS packages installation. > > > > Is there a quick setup that I could use? > > > > I am doing the installation thru network, I downloaded the > > newest Minimal Debian CD and there are not many options. > > > > I use a Nvidia board and it was recognized by the LINUX. > > > > Regards, > > > > FS > > Are you trying to install the debian packages for PLib, Simgear & > FlightGear or do you want to use the cvs versions? > > LeeE > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > - This mail sent through IMP: http://horde.org/imp/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayer crashes with unknown aircrafts, any solution?)
Oliver Schroeder wrote: > Apperantly gcc under cygwin uses a different alignment for structs > than gcc under linux (I don't know which gcc version is used under > cygwin). At home I use gcc 3.3.6, and it reports: Yet another reason why blasting raw structures out an I/O channel (especially a network socket!) is just always a bad idea. Really, to make this work without major insanity we have to cook the output. No doubt the cygwin compiler is defaulting to the MSVC standard alignment rules. Note that you can change these at compile time under both compilers by using command line switches and/or #pragma directives, etc... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Debian Installation
Le mercredi 27 juillet 2005 à 11:58 -0300, [EMAIL PROTECTED] a écrit : > LeeE > > I am trying to install plib and I got errors, it seems to be "Mesa" that is > not > installed. > > > > cd plib-1.8.4/ > ../configure > > .. > .. > .. > checking for IceConnectionNumber in -lICE... no > checking for pthread_create in -lpthread... no > checking for glNewList in -lGL... no > checking for glNewList in -lMesaGL... no > configure: error: could not find working GL library > > > Wich package is missing? > > Regards, > > FS > > About GL the development package is missing. Or coming from Debian Or coming from your Graphics card package ( ie Nvidia package installation ) > > > -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Debian Installation
Did you use the install utility to update/upgrade your Debian packages? Which version are you using? Stable->woody or Testing->Sarge? In either case you need the glut3g-dev or freeglut-dev packages installed to get the header and library files. Look in /usr/include/GL for the GL headers. If missing try "apt-get install glut3g-dev" or whichever library package you prefer from the set of development graphic packages provided on the Debian website. Regards JW - Original Message - From: "Gerard Robin" <[EMAIL PROTECTED]> To: "FlightGear developers discussions" Sent: Wednesday, July 27, 2005 10:36 AM Subject: Re: [Flightgear-devel] Debian Installation Le mercredi 27 juillet 2005 à 11:58 -0300, [EMAIL PROTECTED] a écrit : > LeeE > > I am trying to install plib and I got errors, it seems to be "Mesa" that is not > installed. > > > > cd plib-1.8.4/ > ../configure > > .. > .. > .. > checking for IceConnectionNumber in -lICE... no > checking for pthread_create in -lpthread... no > checking for glNewList in -lGL... no > checking for glNewList in -lMesaGL... no > configure: error: could not find working GL library > > > Wich package is missing? > > Regards, > > FS > > About GL the development package is missing. Or coming from Debian Or coming from your Graphics card package ( ie Nvidia package installation ) > > > -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
On Wed, 27 Jul 2005 14:18:34 +0200, Gerard wrote in message <[EMAIL PROTECTED]>: > I did NOT ask for deleting that piece of code which is rather good > (and could be improved), > i only ask for to remove the new AGL test >^^ > which delete the UNDERCARIAGE facilities. > > Am i understandable ? ..well, not neccessarily in the precise way you intended to, if you're in doubt, also write in your native language so we can play with babelfish.org, a couple of your recent post reads out far worse in english than what I believe you meant them to. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
Le mercredi 27 juillet 2005 à 23:15 +0200, Arnt Karlsen a écrit : > On Wed, 27 Jul 2005 14:18:34 +0200, Gerard wrote in message > <[EMAIL PROTECTED]>: > > > I did NOT ask for deleting that piece of code which is rather good > > (and could be improved), > > i only ask for to remove the new AGL test > >^^ > > which delete the UNDERCARIAGE facilities. > > > > Am i understandable ? > > ...well, not neccessarily in the precise way you intended to, if > you're in doubt, also write in your native language so we can > play with babelfish.org, a couple of your recent post reads out > far worse in english than what I believe you meant them to. ;o) > for BabeFish.org En français j'écrirai exactement la même chose. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RSA meeting 2005; Was: Model submission [...]
The topic stems from a private EMail conversation On Fri, Apr 01, 2005 at 02:19:43PM +0200, Martin Spott wrote: > On Fri, Apr 01, 2005 at 02:09:15PM +0200, Frederic Bouvier wrote: > > Quoting Martin Spott : > > > > > P.S.: The next RSA meeting in July (every third weekend in July) takes > > > place at Nevers. Would you bother to visit this meeting ? [...] > Matthew Law considered to attend the meeting, I myself will be there - > I thought we probably could have a meeting of the "European FlightGear > Fraternity" at Nevers ;-) Actually, did anyone besides me get there ? I asked at the registration but they didn't have a any known name from the FlightGear-'community' listed. They have started collecting photos for their website. To get an impression of this meeting, look here: http://www.rsafrance.com/Nevers2005/ It was pretty crowded this year on a much smaller airport than the previous years, lots of interesting people and aircraft were present. Unfortunately one racer didn't get back to the runway: http://document.ihg.uni-duisburg.de/bitmap/Nevers_Crash-02.jpg but fortunately the pilot survived. Unfortunately this man was the main coordinator of the meeing which resulted in a cancellation of the further 'program' on sunday afternoon. The photo is taken from the coverpage of the newspaper "Le Journal Du Centre". BTW, it was _terribly_ hot at nevers but the weather was excellent. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] VOIP radio (was: feature request...)
There's also GnomeMeeting which uses H.323 (I think via an external library). The biggest problems I see are doing multicasting and automatic hook-up with people "flying" in the same area. Oh, and making sure the I/O is done using a cross-platform library. Ideally I suppose this should be done as a separate project so other apps can make use of it. All the parts are there, but it sounds like a large amount of glue and polish to do it well. Paul On Sat, 2005-07-23 at 13:57 -0400, Ampere K. Hardraade wrote: > On July 23, 2005 12:03 pm, Paul Surgeon wrote: > > What a pity as I don't know of any good replacements and writing VOIP > > software is not a trivial task. > Doing an apt-cache search voip get me kphone and libopenh323. > > > > Ampere > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] fluxgate compass
I am making a flux gate compass instrument that is gyro stabilized. Is there a property that reflects heading with magnetic declination but does not read incorrectly in a dive or bank? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
