Re: [Flightgear-devel] GIT / SVN
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Turner > > > > - git works great on the Mac, or any Unix, but I believe it's never going to fly (if you'll pardon the expression) on Windows, due to technical limitations there > > FWIW, Cygwin provides git (V1.5.3.5) for Windows systems. I know that the majority of development on Windows is now done with MSVC, but isn't Cygwin still required at the moment for something? Terrasync perhaps? Richard - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Blackout/Redout
On jeu 21 août 2008, Erik Hofman wrote: > gerard robin wrote: > > I mainly wonder if the basic calculation for the g-load is right. I have > > copied from the F16 (by Eric) the "g load corrected" which is > > > > > > accelerations/n-pilot-z-norm > > -fcs/n-pilot-z-correction > > > > It si both right and wrong. I reality when standing on a runway the > pilot encounters 1G positive due to gravity. This is (probably) what is > required for red-out and black-out situations. > > The corrected g-load is to compensate for gravity within the flight > computer. Without the correction it will pitch down when trying to > fulfill the pilots commanded 0G (or level flight). So the correction is > purely for fly-by-wire systems and should not be used for black-outs. > > Erik > Eric, Thanks, I was not sure about it. That is the opportunity to say that your "new" F16 is, to me, a great pleasure to fly. 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Sound positioning and orientation
Hi, I'm working on proper Listener positioning for sound playback in FlightGear and encountered a difference between the coordinate system described in README.xmlsound (which describes a right handed system that doesn't exists, it describes a left handed system instead) and the actual coordinate system of OpenAL (which is directly used, without any conversions, at the moment). There are two options, modify the code to reflect what is described in README.xmlsound or modify the README file. I think I already know the answer, but which of the two is preferred by others? If no one cares that much I'll modify the SimGear code to reflect what is described in the README file to prevent the need to modify too many configuration files. 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound positioning and orientation
On 21 Aug 2008, at 13:25, Erik Hofman wrote: > I'm working on proper Listener positioning for sound playback in > FlightGear and encountered a difference between the coordinate system > described in README.xmlsound (which describes a right handed system > that > doesn't exists, it describes a left handed system instead) and the > actual coordinate system of OpenAL (which is directly used, without > any > conversions, at the moment). Wow, great that you're working on this, it was something on my medium term list of things to consider. While you're at it, can you make the sounds code be a proper subsystem, and also remove the dependency on the viewer classes by getting the listener information from the property tree? I.e migrate the ugly code out of the main loop in main.cxx. 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound positioning and orientation
James Turner wrote: > On 21 Aug 2008, at 13:25, Erik Hofman wrote: > >> I'm working on proper Listener positioning for sound playback in >> FlightGear and encountered a difference between the coordinate system >> described in README.xmlsound (which describes a right handed system >> that >> doesn't exists, it describes a left handed system instead) and the >> actual coordinate system of OpenAL (which is directly used, without >> any >> conversions, at the moment). > > Wow, great that you're working on this, it was something on my medium > term list of things to consider. > > While you're at it, can you make the sounds code be a proper > subsystem, and also remove the dependency on the viewer classes by > getting the listener information from the property tree? I.e migrate > the ugly code out of the main loop in main.cxx. I knew it! :) Ok, I' l take a look at that, good idea. 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] osgDB ac3d reader: detected surface with less than 3 vertices!
Hello, Does anybody, here, knows, how to know, which .ac model/object gives the following warning message, during FG loading ? osgDB ac3d reader: detected surface with less than 3 vertices! Which model/object name is involved? It is rather easy when the AC is made of a very little quantity of objects , and easy to solve. But, very, very difficult to find when that AC is made of more than 50 objects :(. 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound positioning and orientation
On 21 Aug 2008, at 13:33, Erik Hofman wrote: > I knew it! :) > Ok, I' l take a look at that, good idea. One of the things on my medium-term list is to carry on the subsystem- ification work. To reach the ultimate goal (mainloop just does 'update' on the subsystemgr) will take a long time, but there's a lot of low-hanging fruit, and it all gets code out of Main/, which can only be a good thing. 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] osgDB ac3d reader: detected surface with less than 3 vertices!
gerard robin wrote: > > Hello, > > Does anybody, here, knows, how to know, which .ac model/object gives the > following warning message, during FG loading ? > osgDB ac3d reader: detected surface with less than 3 vertices! > Which model/object name is involved? > > It is rather easy when the AC is made of a very little quantity of objects > , > and easy to solve. > But, very, very difficult to find when that AC is made of more than 50 > objects :(. I had to make sure I had to run 'optimize vertices' and 'optimize surfaces' on all objects to get rid of these warnings. It's a good thing though that there is a warning for it. 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] osgDB ac3d reader: detected surface with less than 3 vertices!
On jeu 21 août 2008, Erik Hofman wrote: > gerard robin wrote: > > Hello, > > > > Does anybody, here, knows, how to know, which .ac model/object gives > > the following warning message, during FG loading ? > > osgDB ac3d reader: detected surface with less than 3 vertices! > > Which model/object name is involved? > > > > It is rather easy when the AC is made of a very little quantity of > > objects , and easy to solve. > > But, very, very difficult to find when that AC is made of more than 50 > > objects :(. > > I had to make sure I had to run 'optimize vertices' and 'optimize > surfaces' on all objects to get rid of these warnings. It's a good thing > though that there is a warning for it. > > Erik > That is exactly the problem, because, in spite of the "optimize vertices/surfaces " some vertices could remain. This don't remove the "dead" vertices. :( However, to remove them , we must first to know which .ac model is involved 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound positioning and orientation
James Turner wrote: > On 21 Aug 2008, at 13:33, Erik Hofman wrote: > >> I knew it! :) >> Ok, I' l take a look at that, good idea. > > One of the things on my medium-term list is to carry on the subsystem- > ification work. To reach the ultimate goal (mainloop just does > 'update' on the subsystemgr) will take a long time, but there's a lot > of low-hanging fruit, and it all gets code out of Main/, which can > only be a good thing. This is now committed for the SGSoundMgr code, it has been moved tot FGFX. 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Sound fg_fx.cxx, 1.26, 1.27 fg_fx.hxx, 1.17, 1.18
On 21 Aug 2008, at 15:26, Erik Hofman wrote: > + FGViewer *current_view = globals->get_current_view(); > + > + // get the orientation > + const SGQuatd view_or = current_view->getViewOrientation(); > + SGQuatd surf_or = SGQuatd::fromLonLatDeg( > + current_view->getLongitude_deg(), current_view- > >getLatitude_deg()); > + SGQuatd model_or = SGQuatd::fromYawPitchRollDeg( > + globals->get_aircraft_model()->get3DModel()- > >getHeadingDeg(), > + globals->get_aircraft_model()->get3DModel()->getPitchDeg(), > + globals->get_aircraft_model()->get3DModel()->getRollDeg()); Ah, what I was really hoping to do, was to break the dependency on the FGViewer, and globals->get_aircraft_model(), by getting the equivalent position and orientation from the property tree. I haven't checked how straightforward that is, but having the sound code so intimately hooked up to the view code like this isn't ideal. Not to sound negative, I realise it's a case of improving one thing at a time. 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT / SVN
Richard Bytheway wrote > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > James Turner > > > > > > > > - git works great on the Mac, or any Unix, but I believe it's never > going to fly (if you'll pardon the expression) on Windows, due to > technical limitations there > > > > > > FWIW, Cygwin provides git (V1.5.3.5) for Windows systems. I know that > the majority of development on Windows is now done with MSVC, but isn't > Cygwin still required at the moment for something? Terrasync perhaps? > > Richard > Yes, Cygwin is still required for Terrasync, and for patching as well. Its Git utility isn't exactly user-friendly, but if you are used to CVS with Cygwin, the transition to Git isn't difficult. I would guess for most Windows user this is all too much hassle though There is a Windows client for Git: Git-gui, but I can't locate a download site for it atm. I've been using it for a while. It's not brilliant. Tortoise CVS/SVN is much easier. Frankly WinCVS is better than Git-gui, and in some ways better then Tortoise CVS or SVN. I use whichever is more convenient at the time. Vivian - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Tool available to build an aircraft
Hi, I am wondering if there is a tool available for a person that has no experience to create an aircraft in flightgear to use. Thank's for your help. Sophia - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound positioning and orientation
On 21 Aug 2008, at 15:31, Erik Hofman wrote:
> This is now committed for the SGSoundMgr code, it has been moved tot
> FGFX.
Just in case you care, my longer term plan for the sound code was to
create an SGSoundSource (in the simgear code), which would basically
be a wrapper around an OpenAL source. This could then be hung off an
AIModel, and potentially, we could add a new kind of multiplayer
message to trigger a sound remotely.
something like (incomplete!):
class SGSoundSource
{
public:
void setVelocity(SGVec3d)
void setOrientation(SGQuatd)
void setPosition(); // either cart or geod, whichever makes more sense
void playOnce(... sound id , ampltidue );
void playLooped( same as above , loopCount or -1);
}
That's me guessing wildly, but feels about right - and very easy to
hook into the AI / MP code. Probably want a Nasal interface for it as
well.
Quite far down my current ToDo list, though.
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=100&url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound positioning and orientation
On Thu, 21 Aug 2008, James Turner wrote: > > On 21 Aug 2008, at 15:31, Erik Hofman wrote: > >> This is now committed for the SGSoundMgr code, it has been moved tot >> FGFX. > > Just in case you care, my longer term plan for the sound code was to > create an SGSoundSource (in the simgear code), which would basically > be a wrapper around an OpenAL source. This could then be hung off an > AIModel, and potentially, we could add a new kind of multiplayer > message to trigger a sound remotely. Why not trigger multiplayer sounds via property changes (in the same way as most of the other sounds are handled)? Switching to only sending properties when they change would make it feasible to have a bunch of MP enabled properties for the sounds. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
Here's another "for what it's worth" ... I was able to find a set of options to the cvs2svn tool that worked for our repository. The FlightGear repository takes about an hour and 45 minutes to convert. So that part works well. I also really like how svn handles group and user authentication ... it does it outside of the unix account system which makes the system much easier to manage. But I am headed out of town here in a few minutes so I didn't want to rush to set up a server daemon and then overlook something from a security standpoint. >From the standpoint of taking small steps, I think it makes sense to migrate towards svn, and then we can still keep the git discussion open as a separate issue. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - 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=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound positioning and orientation
On 21 Aug 2008, at 17:02, Anders Gidenstam wrote: > Why not trigger multiplayer sounds via property changes (in the same > way > as most of the other sounds are handled)? > > Switching to only sending properties when they change would make it > feasible to have a bunch of MP enabled properties for the sounds. I'm not familiar enough with how 'other' sounds are handled to be sure, but my issue is that currently all 'positioned' sounds originate from the aircraft - there needs to be some additional data/struct/ class exposed at the C++ level to specify a bit more information about sources. Of course it can have a Nasal interface, but I have the impression you're talking about something a bit different. Changing MP to only send properties when the change is a separate, but worthwhile improvement, I guess, but I don't (again) know enough to comment for sure. And equally, there's plenty of scope to add new MP messages types, the same way chat is currently handled. For 'event'y thing like playing a one-off sounds, using property changes doesn't seem exactly elegant to me, though I know it's a common idiom. 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound positioning and orientation
On Thu, 21 Aug 2008, James Turner wrote: > I'm not familiar enough with how 'other' sounds are handled to be > sure, but my issue is that currently all 'positioned' sounds originate > from the aircraft - there needs to be some additional data/struct/ > class exposed at the C++ level to specify a bit more information about > sources. Of course it can have a Nasal interface, but I have the > impression you're talking about something a bit different. My comment was on the talk about adding extra MP message types for sound. I'm not familiar with the sound internals, but sounds created by a MP/AI model should of course be positioned relative to that model. So adding that possibility would be great. > Changing MP to only send properties when the change is a separate, but > worthwhile improvement, I guess, but I don't (again) know enough to > comment for sure. And equally, there's plenty of scope to add new MP > messages types, the same way chat is currently handled. For 'event'y > thing like playing a one-off sounds, using property changes doesn't > seem exactly elegant to me, though I know it's a common idiom. Using properties would match nicely with the XML sound configs and be analogous to the way animation of MP/AI 3d models are handled. Btw, if you mean the "in-program" chat I'm fairly sure it is done using a MP enable string property. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
On 21 Aug 2008, at 16:46, Curtis Olson wrote: > I was able to find a set of options to the cvs2svn tool that worked > for our repository. The FlightGear repository takes about an hour > and 45 minutes to convert. So that part works well. Yep, that's really great news - I have heard some horror stories from the early days of SVN, but it seems to be a straightforward process these days > I also really like how svn handles group and user > authentication ... it does it outside of the unix account system > which makes the system much easier to manage. But I am headed out > of town here in a few minutes so I didn't want to rush to set up a > server daemon and then overlook something from a security standpoint. Can't comment much there - I've used the HTTPS interface, where authentication was done by Apache, but of course there's multiple Apach mod_auth_ solutions. > From the standpoint of taking small steps, I think it makes sense to > migrate towards svn, and then we can still keep the git discussion > open as a separate issue. Yep, absolutely, especially since I am very unsure how git deals with binary files, and the Windows situation seems 'complicated'. 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Sound fg_fx.cxx, 1.26, 1.27 fg_fx.hxx, 1.17, 1.18
James Turner wrote: > Ah, what I was really hoping to do, was to break the dependency on the > FGViewer, and globals->get_aircraft_model(), by getting the equivalent > position and orientation from the property tree. I haven't checked how > straightforward that is, but having the sound code so intimately > hooked up to the view code like this isn't ideal. I did understand that but I have to look better to see if that is indeed a better solution, C++ structures still do have their use once in a while and properties aren't always the best solution when dealing with settings in the program itself. But .. it might well be in this case. Anyhow, cleaning up the main loop was the first priority for 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Sound fg_fx.cxx, 1.26, 1.27 fg_fx.hxx, 1.17, 1.18
On 21 Aug 2008, at 17:50, Erik Hofman wrote: > But .. it might well be in this case. No, I'm not sure either, it was just a gut feeling that depending on FGViewer was a bit weird, for sound code. > Anyhow, cleaning up the main loop was the first priority for me. Yep, agreed. - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Sound fg_fx.cxx, 1.26, 1.27 fg_fx.hxx, 1.17, 1.18
James Turner wrote: > On 21 Aug 2008, at 17:50, Erik Hofman wrote: > >> But .. it might well be in this case. > > No, I'm not sure either, it was just a gut feeling that depending on > FGViewer was a bit weird, for sound code. Well, it's called a Listener for OpenAL, but they are both located at the same location an are both 'looking' at the same direction. It's really not that weird. 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
On 08/20/2008 02:32 PM, Curtis Olson wrote: > Perhaps I misunderstand the scope and capabilities of git > And at the end of the day, no matter what source code version control system > we use, and no matter what useful tools it provides for branching and > merging, we still need a human in the loop to act as a sanity check to > evaluate and approve changes that go into the master repository. Huh? Has anyone suggested otherwise? > (I > understand this is a philosophical choice on my part. Another approach > would be to let any and all changes from just about anyone to be committed > to the master repository and let the review step happen when things break or > crash or stop functioning optimally ... I just do not like that particular > approach.) Why are we even discussing such wildly unprofessional approaches? Consider the Linux kernel, which could be considered the flagship application for git. Does anybody think that submissions to the official main branch of the kernel go in without a human in the loop? Does anybody think kernel code gets reviewed only "when things break or crash or stop functioning optimally"? Let's be clear: I can think of some projects that have conspicuously broken review mechanisms ... but they are projects that don't use git, not projects that do. > Perhaps I misunderstand the scope and capabilities of git One of git's raisons d'être is precisely this, to make it *easier* to evaluate submissions before they are committed to the main branch. It achieves this in part by making it super-easy and quick to create new branches ... and then to throw them away if/when they are no longer needed. It is already being used in this way by FGFS developers, and has been for some time. - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] AirportList.cxx does not include config.h
Somebody please add config.h to AirportList.cxx, because the #include (in AirportList.hxx) needs the PU_USE_NONE define. Thanks. -- Csaba/Jester - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AirportList.cxx does not include config.h
Hi Czaba, Done!. Out of Curiosity: On which system did you see the error? I'm working on Suse Linux 11.0 (64 bit), and everything compiled just fine. Cheers, Durk On Thursday 21 August 2008 21:52:05 Csaba Halász wrote: > Somebody please add config.h to AirportList.cxx, because the #include > (in AirportList.hxx) needs the PU_USE_NONE define. - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AirportList.cxx does not include config.h
On Thu, Aug 21, 2008 at 10:16 PM, Durk Talsma <[EMAIL PROTECTED]> wrote: > > Done!. Out of Curiosity: On which system did you see the error? I'm working > on Suse Linux 11.0 (64 bit), and everything compiled just fine. Thanks! Plib defaults to glut if it isn't told otherwise. So as long as you have glut installed (which I don't) it should compile ok. Not sure if having this part of the code compiled for glut and the rest for osgviewer has any run-time effects. -- Csaba/Jester - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Traffic Manager II
On Thursday 31 July 2008 21:22, Durk Talsma wrote: > For the adventurous, I've also posted a snapshot of the current code > (source only). Feedback is appreciated. > For those interested, here's another snapshot of the current in development code of the traffic manager: http://durktalsma.xs4all.nl/FlightGear/FlightGear-1.0.0-new-traffic-manager-prev2.tar.gz The main improvement of the current code is that I've switched to a more efficient search mechanism to link Aircraft and Flights. There are still a few things left to do before the code is ready for CVS: - Switch the file format back to xml - Ensure backward compatibiliy (it's actually fairly easy to do) - More cleanup. There is also the accompanying data file. This file contains a broad selection of Flights to and from EHAM, based on the August 2008 time table. All required AI aircraft should be in the CVS data package now. http://durktalsma.xs4all.nl/FlightGear/new-traffic-data-prev2.zip Finally, the new code works extremely well in combination with the new EHAM terminal buildings that Gijs is working on. Reason to add a few more screenshots to my FlightGear AI " in development" webpage: http://durktalsma.xs4all.nl/FlightGear/web/75.html Enjoy! Durk - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
John Denker wrote: > On 08/20/2008 02:32 PM, Curtis Olson wrote: > > Perhaps I misunderstand the scope and capabilities of git > > And at the end of the day, no matter what source code version control system > > we use, and no matter what useful tools it provides for branching and > > merging, we still need a human in the loop to act as a sanity check to > > evaluate and approve changes that go into the master repository. (I > > understand this is a philosophical choice on my part. Another approach > > would be to let any and all changes from just about anyone to be committed > > to the master repository and let the review step happen when things break or > > crash or stop functioning optimally ... I just do not like that particular > > approach.) > Why are we even discussing such wildly unprofessional approaches? Nobody does, I guess. Curt just seems to be a bit desperate about defending his refusal of an 'official' GIT mirror here. Maybe he simply ran out of arguments, so he finally decided to draw a black-and-white picture and sort of imply that those, who don't share his (Curt's) view, would be in favour of what we all consider to be the worst case. In fact, the scenario that Curt is describing here has nothing to do with the facual topic of the whole discussion. Personally I count the cited paragraph as a regrettable mistake. Sorry, I know that these remarks sound a bit merciless and are likely to lower the chances to get an official blessing for 'my' GIT repo. Yet I prefer to play honest and with open cards instead to chum up with someone just for the purpose of becoming FlightGear's first 'official' GIT maintainer Regards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
Curtis Olson wrote: > Here's another "for what it's worth" ... > > I was able to find a set of options to the cvs2svn tool that worked for > our repository. The FlightGear repository takes about an hour and 45 > minutes to convert. So that part works well. I also really like how > svn handles group and user authentication ... it does it outside of the > unix account system which makes the system much easier to manage. But I > am headed out of town here in a few minutes so I didn't want to rush to > set up a server daemon and then overlook something from a security > standpoint. > > From the standpoint of taking small steps, I think it makes sense to > migrate towards svn, and then we can still keep the git discussion open > as a separate issue. > I think this is a reasonable compromise. While I think that git is great and that the Windows client issues will be non-issues soon, there is good support in git for interacting (bi-directionally) with SVN repositories. I believe that git-svn will, given the same command line options, always generate the same sha1 hash for an SVN commit, so people who want to pull patches from other developers' git repositories should be able to do that without too much trouble. 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound positioning and orientation
Hi Erik, Erik Hofman schrieb am 21.08.2008 14:25: > Hi, > ... > There are two options, modify the code to reflect what is described in > README.xmlsound or modify the README file. > > I would prefer to modify the README file. I made some asymmetric sound for helicopters (S58, bo105) and adjusted them, that the result give the correct sound. But if there are other aircrafts with asymmetric sound (e. g. multi engine aircrafts), which have "wrong" sound now... Does anyone know of an aircraft, with "wrong" sound? > I think I already know the answer, but which of the two is preferred by > others? > > If no one cares that much I'll modify the SimGear code to reflect what > is described in the README file to prevent the need to modify too many > configuration files. > > I am not sure, if there is any need to modify configuration files if only the documentation is corrected. > Erik > Maik - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
Martin Spott wrote: > John Denker wrote: >> On 08/20/2008 02:32 PM, Curtis Olson wrote: > >>> Perhaps I misunderstand the scope and capabilities of git > >>> And at the end of the day, no matter what source code version control system >>> we use, and no matter what useful tools it provides for branching and >>> merging, we still need a human in the loop to act as a sanity check to >>> evaluate and approve changes that go into the master repository. (I >>> understand this is a philosophical choice on my part. Another approach >>> would be to let any and all changes from just about anyone to be committed >>> to the master repository and let the review step happen when things break or >>> crash or stop functioning optimally ... I just do not like that particular >>> approach.) > >> Why are we even discussing such wildly unprofessional approaches? > > Nobody does, I guess. Curt just seems to be a bit desperate about Some projects do support a "mob" branch in git where anyone can commit anything. Hell, why not? :) > defending his refusal of an 'official' GIT mirror here. Maybe he simply > ran out of arguments, so he finally decided to draw a black-and-white > picture and sort of imply that those, who don't share his (Curt's) > view, would be in favour of what we all consider to be the worst case. > In fact, the scenario that Curt is describing here has nothing to do > with the facual topic of the whole discussion. > Personally I count the cited paragraph as a regrettable mistake. In fairness Linus does talk up git's extreme support for forking, and there are many Linux trees to choose from; the reality is that you know where to go for something reliable. 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] AI Carrier and solid Objects
Hello, AI Carrier wants the definition That definition gives to the Aircraft the solid material which is necessary to land, to taxis and to take off (mainly the deck and hangar). That definition is useful too, to define the main obstacles (mainly island, and hull ) With FG PLIB we could define being a group name or an object name. It was very useful to be able to define it with group name, (spare time to make it and easier to maintain it) With FG OSG only object name is working, any group name which is given don't work. You may notice that, Foch carrier which has group name, was right with FG PLIB, is not usable like it is into CVS with FG CVS. I wonder why we don't we have with OSG the same feature, as we had with PLIB Regards -- 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
