Re: [Flightgear-devel] git work flow question

2011-01-26 Thread Martin Spott
Curtis Olson wrote:

 The other implication here is that it would be extremely handy to have
 multiple branches checked out simultaneously for other reasons.  git makes
 branching easy, yes, but if you find yourself bouncing between branches with
 changes for separate projects, and external events may require you to jump
 to a different branch at a moments notice, It's a major PITA to have to
 commit every little thing you are in the middle of to switch to another
 branch.
 
 This is like having to completely clean up your desk before you can work on
 a new task, and then clean it up again completely before you can jump to the
 next.

I think you're looking after having multiple local clones of the same
repository where you're checking out a different branch in each of
them,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] VATSIM support?

2011-01-26 Thread Martin Spott
Chris,
I think the benefit of having sort of a VATSIM-interface or -bridge for
FlightGear is pretty much unquestioned, therefore I'll leave these
details out. The point is a completely different one and probably
consist of just two simple parts:

1.) Like probably almost every other OpenSource projects, FlightGear
attracts its developer crowd (some would call it community) by the
features which are specific to OpenSource development in general: Free
access to the source code, multiple people working more or less
collaboratively on the same part/feature, shared responsibility and
certainly a lot more.
This is fundamentally different from the development model you'd be
forced into after signing an NDA: The NDA would presumably make almost
every flavour of collaboration and peer-review impossible and the
respective developer would end up as the sole responsible person for
interfacing a variety of different FlightGear versions on a colourful
bouquet of different platforms. Doesn't sound too attractive 

Chris O'Neill wrote:

 Correct me if I'm wrong, but what VATSIM seems to be saying is that they
 don't want just anybody trying to connect to their network, hence the
 only approved clients policy, and in order to enforce that policy they
 want to be the only source for releasing the source code.

As far as I can tell the we need to protect our sim network is void.
If they really make this claim, I'd consider it as a specious argument.
To put it into different words: I know of at least three distinct
implementations of VATSIM network protocols which had been created
without VATSIM's help by reverse engineering. Thus, if anyone is
seriously interested in compromising their network, there are
sufficient opportunities to do so.
One of the three people who reverse-engineered VATSIM-protocols was
saying in a joke that he suspected the main reason for VATSIM to keep
their protocol secret was not to disclose how poorly designed it is  :-)

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] VATSIM support?

2011-01-26 Thread Arnt Karlsen
On Wed, 26 Jan 2011 09:56:41 + (UTC), Martin wrote in message 
ihor4p$ls0k$1...@osprey.mgras.de:

 Chris,
 I think the benefit of having sort of a VATSIM-interface or -bridge
 for FlightGear is pretty much unquestioned, therefore I'll leave these
 details out. The point is a completely different one and probably
 consist of just two simple parts:
 
 1.) Like probably almost every other OpenSource projects, FlightGear
 attracts its developer crowd (some would call it community) by the
 features which are specific to OpenSource development in general: Free
 access to the source code, multiple people working more or less
 collaboratively on the same part/feature, shared responsibility and
 certainly a lot more.
 This is fundamentally different from the development model you'd be
 forced into after signing an NDA: The NDA would presumably make almost
 every flavour of collaboration and peer-review impossible and the
 respective developer would end up as the sole responsible person for
 interfacing a variety of different FlightGear versions on a colourful
 bouquet of different platforms. Doesn't sound too attractive 

..and then there is the litigation risk, if you don't read 
nor sign any NDA, you can not violate that agreement.

..if you do sign a NDA, you risk having to hire an expensive 
contract law lawyer to try convince a pro-business judge that 
you the progressive pro-community hobbyist hacker did not 
do what that big business law team _claims_ you did. 

..http://groklaw.net/ has _several_ such stories, where even 
Big Blue has been stuck for over 7 years in US courts.

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...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.

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] JSBSim merge

2011-01-26 Thread Erik Hofman
On Mon, 2011-01-24 at 15:40 +, James Turner wrote:

 Okay - I'm going to re-apply my patches locally, and also apply Andreas 
 Gaeb's NaN fixes (and to the release branch too), but of course they all need 
 to be merged to JSBSim proper.

After a bit of discussion it was decided that the FlightGear/JSBSim glue
code in JSBSim.[ch]xx located in FlightGear/src/FDM/JSBSim now is
maintained by FlightGear developers instead of by JSBSim developers and
therefore these files will not be overwritten in future updates. Instead
they are now copied over to JSBSim instead to act as example code.

Erik


--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] JSBSim merge

2011-01-26 Thread James Turner

On 26 Jan 2011, at 11:55, Erik Hofman wrote:

 After a bit of discussion it was decided that the FlightGear/JSBSim glue
 code in JSBSim.[ch]xx located in FlightGear/src/FDM/JSBSim now is
 maintained by FlightGear developers instead of by JSBSim developers and
 therefore these files will not be overwritten in future updates. Instead
 they are now copied over to JSBSim instead to act as example code.

Great, that simplifies things considerably, hopefully for everyone. There's 
still the issue of my FGPropulsion change, and Andreas' FGPropogate fix to go 
into JSBSim proper.

Regards,
James


--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] JSBSim merge

2011-01-26 Thread Erik Hofman
On Wed, 2011-01-26 at 12:23 +, James Turner wrote:
 On 26 Jan 2011, at 11:55, Erik Hofman wrote:
 
  After a bit of discussion it was decided that the FlightGear/JSBSim glue
  code in JSBSim.[ch]xx located in FlightGear/src/FDM/JSBSim now is
  maintained by FlightGear developers instead of by JSBSim developers and
  therefore these files will not be overwritten in future updates. Instead
  they are now copied over to JSBSim instead to act as example code.
 
 Great, that simplifies things considerably, hopefully for everyone. There's 
 still the issue of my FGPropulsion change, and Andreas' FGPropogate fix to go 
 into JSBSim proper.

I've committed Andreas' FGPropogate fix in JSBSim, your fix needs some
more discussion and testing I'm afraid.

Erik


--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] JSBSim merge

2011-01-26 Thread Jon S. Berndt
 -Original Message-
 From: Erik Hofman [mailto:e...@ehofman.com]
 Sent: Wednesday, January 26, 2011 5:55 AM
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] JSBSim merge
 
 On Mon, 2011-01-24 at 15:40 +, James Turner wrote:
 
  Okay - I'm going to re-apply my patches locally, and also apply
 Andreas Gaeb's NaN fixes (and to the release branch too), but of course
 they all need to be merged to JSBSim proper.
 
 After a bit of discussion it was decided that the FlightGear/JSBSim
 glue
 code in JSBSim.[ch]xx located in FlightGear/src/FDM/JSBSim now is
 maintained by FlightGear developers instead of by JSBSim developers and
 therefore these files will not be overwritten in future updates.
 Instead
 they are now copied over to JSBSim instead to act as example code.
 
 Erik

I have received and applied patches from several places recently. Make sure
that patches are not accidentally reversed.

It is very important that patches - and *very*especially* **any** patches to
FGPropagate - go through the proper channels, tested thoroughly using
several specified scripts on the JSBSim side. All patches must be posted
and/or explained on the JSBSim developer list first prior to being
committed.

I'm not writing this to be heavy-handed, but to avoid problems going
forward, based on past experiences. Sometimes I will see problem reports in
various places and be working locally on the best approach for a fix. So,
merging *from* the flightgear tree to JSBSim might cause problems when I try
to apply my (or another JSBSim developer's) fixes.

So, let's please funnel ALL problem reports about JSBSim issues to the
JSBSim developer list OR via the bug reporting tool:

https://sourceforge.net/tracker/?atid=119399group_id=19399func=browse

Thanks - and sorry if this comes across as rude or controlling. It's not
meant to. 

:-)


Jon



--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] JSBSim merge

2011-01-26 Thread James Turner

On 26 Jan 2011, at 12:26, Erik Hofman wrote:

 Great, that simplifies things considerably, hopefully for everyone. There's 
 still the issue of my FGPropulsion change, and Andreas' FGPropogate fix to 
 go into JSBSim proper.
 
 I've committed Andreas' FGPropogate fix in JSBSim, your fix needs some
 more discussion and testing I'm afraid

That's absolutely fine - I freely admit to knowing nothing about JSBSim 
internals!

James


--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] JSBSim merge

2011-01-26 Thread Erik Hofman
On Wed, 2011-01-26 at 07:19 -0600, Jon S. Berndt wrote:

 I have received and applied patches from several places recently. Make sure
 that patches are not accidentally reversed.

They won't since the patches at the FlightGear side will be overwritten
by what JSBSim had in CVS.

 It is very important that patches - and *very*especially* **any** patches to
 FGPropagate - go through the proper channels, tested thoroughly using
 several specified scripts on the JSBSim side. All patches must be posted
 and/or explained on the JSBSim developer list first prior to being
 committed.

I've applied one that can only be harmless, initializing to zero for
certain arguments upon reset. The other one needs to be looked at, like
described in the JSBSim mailing list.

Erik


--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] git work flow question

2011-01-26 Thread Andy Ross
[saw this in time to de-lurk]

On 01/25/2011 11:22 AM, Anders Gidenstam wrote:
 I suspect the option --local to git clone might be useful.
 I have not tried myself, though.

Yeah, this is the best answer for this kind of problem.

The .git directory ends up being near-zero size (so long as the deltas
between trees are small), and you pay only for the copy of the active
tree.  So resource consumption is more or less the same as having two
checkouts of a remote tree.

You do have to manage the extra steps required to push/pull/merge
between the trees though.

Andy

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] list of aircraft that don't load in fgdata

2011-01-26 Thread Anders Gidenstam
On Tue, 25 Jan 2011, dave perry wrote:

 I have tried to load several AC that did not load with filed to load
 file name errors.  So I did a survey of the entire up-to-date
 fgdata.  I used an up-to-date fgrun and went through all the AC.

 The following do not load even to the viewer in fgrun:
 737-100, 737-300, AG-14, Airwave Xtreme 150, CRJ-200, DC-8-63, Fairchild
 Metroliner, Fooker50-Denim, Jaguar, Late-29, marchetti, MIG-29 Fulcrum,
 Mirage F1, North American OV-10A USAFE Bronco, Short Empire, x24b, and
 Zepphelin NT07 multiplayer copilot.

Did you try them in FlightGear too?

As far as I know both Short Empire and ZLT-NT-copilot (the latter doesn't 
have any visible model btw) load fine in FlightGear so if the problems 
with them occur only in fgrun I'd be inclined to consider it a problem in 
fgrun's model viewer rather than a problem in the aircraft.

Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] [FWD: Re: VATSIM support?]

2011-01-26 Thread James J. Brennan
I just sent you a message to what is likely an old and replaced address.

Just wondering if you are still going to come up to do your thing at LUGOD?

jj

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] JSBSim merge

2011-01-26 Thread Bertrand Coconnier
2011/1/26 Erik Hofman e...@ehofman.com:

 After a bit of discussion it was decided that the FlightGear/JSBSim glue
 code in JSBSim.[ch]xx located in FlightGear/src/FDM/JSBSim now is
 maintained by FlightGear developers instead of by JSBSim developers and
 therefore these files will not be overwritten in future updates.

I don't know where this discussion took place so I may have missed the
juicier bits. Then I apologize in advance if my questions have already
been answered.

 Instead they are now copied over to JSBSim instead to act as example code.


Given the decisions taken above, I don't understand why, in the first
place, JSBSim should keep a copy of some code that will now be
maintained elsewhere ? What is the plan ? Porting all patches from
FlightGear to JSBSim's copy ? What for ? AFAICT JSBSim stand-alone
executable is itself an example of how to integrate JSBSim library in
an executable. And JSBSim.[ch]xx seems a fairly complicated chunk of
code to serve as an example. For instance, JSBSim.cpp (the stand-alone
executable) contains 635 lines of code while JSBSim.cxx (the glue
code) contains 1413 lines of code.

Even though, why the name of the Flight Gear glue code has been
changed from JSBSim.[ch]xx to FlightGear.[ch]xx in JSBSim ? Now we
have 2 copies of the same source code with 2 different file names.
What is the point of this renaming ? Is it not confusing ?

2011/1/26 Erik Hofman e...@ehofman.com:
 On Wed, 2011-01-26 at 07:19 -0600, Jon S. Berndt wrote:

 I have received and applied patches from several places recently. Make sure
 that patches are not accidentally reversed.

 They won't since the patches at the FlightGear side will be overwritten
 by what JSBSim had in CVS.

Unless I am mistaken, the plan is now to have a 2-way code exchange
between FlightGear and JSBSim :
FG = JSBSim for JSBSim.[ch]xx/FlightGear.[ch]xx
JSBSim = FG for other JSBSim files.

Who will make sure that those files are always in a consistent state ?

Let's take an example : let's say I develop some code for JSBSim to
take into account FG ground material in the landing gears friction
forces. For that, I need to modify both JSBSim library *and*
FlightGear glue code. So I will submit a patch to JSBSim (for the
friction calcs) and another patch to FlightGear (to give JSBSim access
to FG material data). The patch for FG glue code cannot be applied
readily : first JSBSim needs to be patched and then copied in
FlightGear (or otherwise FG compilation will fail). Once JSBSim last
revision is copied in FlightGear the second part of the patch must be
committed immediately in FlightGear (otherwise FG compilation will
fail). And then the patched glue code will be copied back in JSBSim.
Notice that the patch can be applied at any moment in JSBSim, even 1
month or 1 year after its submission. On the other hand, some tight
synchronization is needed on the FlightGear side if you don't want FG
compilation to break. Do you think such a process is sustainable ? I
don't.

Cheers,

Bertrand.

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] git work flow question

2011-01-26 Thread Curtis Olson
On Wed, Jan 26, 2011 at 1:21 AM, Stefan Seifert n...@detonation.org wrote:

 Well you don't. Often you just can leave modified files in place while
 switching
 branches. If it's not working, you still can simply git stash before
 switching. git stash creates a temporary branch and commits your local
 changes
 to that branch. git stash apply lets you get back those changes, even if
 you're on a different branch than before (it's just like a git merge
 stash).


Hi Stefan,

I created a new branch and then in that branch created some new files and
committed them to that subbranch.  I'm working on those new files.  Any time
I make a change to one of those files and then want to quickly switch to the
master branch I get a lot of these...

$ git checkout master
error: You have local changes to 'Aircraft/foo/bar/newfile'; cannot switch
branches (because this file doesn't exist in master and the branch switch
requires deleting it.)

Ok, I could see git stash helping, but wow, if I start getting a few
branches going, that could potentially be a lot of extra typing and a lot of
things to remember (or go and check) every time I switch branches.  When I
return to a branch do I have to remember to unstash some changes?  If I
forget (life gets complicated sometimes) am I going to waste time chasing
issues I've already fixed?

If I have several branches in play, and someone pushes an important change
to fgdata/master (possibly tied to an important change in flightgear/next)
that can almost lead to an hour of just getting my branches up to date (even
with no direct conflicting files.)

I agree that some changes that have not been committed can float back and
forth through branch switching (just not the ones I'm making right now.) :-)

I found the book Version control with git quite useful. Yes it's somehow
 strange to need a book for a simple tool like a VCS, but git's features are
 IMHO worth having to read a little.


I've barely had a chance to crack open my applying RCS and SCCS O'Reilly
book, and now I have to buy a new book? ... :-)

I personally wouldn't call git a simple tool.  Git takes a highly complex
problem (version control) and splits it up into just about the smallest
possible logical chunks.  Then it leaves it up to the end user to remember
which chunks to stitch together and in which order to achieve the highly
complex task.

Many common tasks are easy in git.  But some things start to become a royal
pain.  Part of this is because I need to adapt my work flow to be more git
compatible.  But I think part of this is that git has some limitations and
weaknesses too, and isn't completely perfect itself.

-- switching gears --

Another thing I do a lot of is work on projects that put me out in the field
or traveling.  So I like to maintain my projects across multiple machines
... my office desktop pc, my laptop, possibly other machines too depending
on the project.

If I'm doing FlightGear based work, and I want to create a special branch
for my little project, *and* I want to share that branch across multiple
PC's and possibly do work at times from any of these PC's ... then I need to
create that branch on a server some place.  Do I want to pollute the
official flightgear repository with a bunch of branches solely for the
purpose of my little side adventures?  Do I create a separate clone on a
separate server and then try to keep those in sync?  At some point I'm going
to have to sit down and think through the whole process of the best way to
share a private branch across multiple PC's ... and keep those all in sync
with each other and the official master repository.

It should be doable I think, but sounds to me like it will require typing a
lot of commands in the right order to make it work right ...

I'm sure there are many ways to make this all work cleanly, but the question
I have is if there's a way to do it that isn't too kludgey/hackish, isn't
too brittle and easily broken by upstream changes, and doesn't require an
unreasonable amount of command steps to accomplish.

Regards,

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org -
http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] list of aircraft that don't load in fgdata

2011-01-26 Thread Heiko Schulz
Hi,


 On Tue, 25 Jan 2011, dave perry
 wrote:
 
  I have tried to load several AC that did not load with
 filed to load
  file name errors.  So I did a survey of
 the entire up-to-date
  fgdata.  I used an up-to-date fgrun and went
 through all the AC.
 
  The following do not load even to the viewer in
 fgrun:
  737-100, 737-300, AG-14, Airwave Xtreme 150, CRJ-200,
 DC-8-63, Fairchild
  Metroliner, Fooker50-Denim, Jaguar, Late-29,
 marchetti, MIG-29 Fulcrum,
  Mirage F1, North American OV-10A USAFE Bronco, Short
 Empire, x24b, and
  Zepphelin NT07 multiplayer copilot.

With the latest FGRun on which OS?
I have problems with some of them on win 32 xp and FGRun: 
AG14, 737-100, Airwave Xtreme 150(no valid mdl-file), CRJ-200, DC-8-63, 
F50-Denim, Jaguar, Late-290, marchetti, MIG-29, Short Empire, 
x24b

HHS





--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] JSBSim merge

2011-01-26 Thread Curtis Olson
Hi Bertrand,

Here are a couple quick responses:

- The reason JSBSim would want to keep a copy of the glue code would be to
serve as an example for others who want to integrate JSBSim into their
projects.

- Changing the name of the glue code (I guess I missed seeing that this was
officially decided).  But if I'm not mistaken, currently we have JSBSim.cxx
and JSBSim.cpp so that is also pretty confusing since they both produce a
JSBSim.o.  It would make sense to call this FlightGear.cxx within the JSBSim
project, probably that's a less informative name within the FlightGear
source tree.

- 2 way patch patch propagation.  Really the only important direction is for
us to merge JSBSim changes into FlightGear.  Merging the glue code changes
back to the JSBSim project would simply be a courtesy to keep the example
code up to date and reduce the chance that some bug or poor way to handle
something is propagated to others (assuming we discover and fix something in
the glue code ourselves.)

Best regards,

Curt.


On Wed, Jan 26, 2011 at 1:53 PM, Bertrand Coconnier wrote:

 2011/1/26 Erik Hofman e...@ehofman.com:
 
  After a bit of discussion it was decided that the FlightGear/JSBSim glue
  code in JSBSim.[ch]xx located in FlightGear/src/FDM/JSBSim now is
  maintained by FlightGear developers instead of by JSBSim developers and
  therefore these files will not be overwritten in future updates.

 I don't know where this discussion took place so I may have missed the
 juicier bits. Then I apologize in advance if my questions have already
 been answered.

  Instead they are now copied over to JSBSim instead to act as example
 code.
 

 Given the decisions taken above, I don't understand why, in the first
 place, JSBSim should keep a copy of some code that will now be
 maintained elsewhere ? What is the plan ? Porting all patches from
 FlightGear to JSBSim's copy ? What for ? AFAICT JSBSim stand-alone
 executable is itself an example of how to integrate JSBSim library in
 an executable. And JSBSim.[ch]xx seems a fairly complicated chunk of
 code to serve as an example. For instance, JSBSim.cpp (the stand-alone
 executable) contains 635 lines of code while JSBSim.cxx (the glue
 code) contains 1413 lines of code.

 Even though, why the name of the Flight Gear glue code has been
 changed from JSBSim.[ch]xx to FlightGear.[ch]xx in JSBSim ? Now we
 have 2 copies of the same source code with 2 different file names.
 What is the point of this renaming ? Is it not confusing ?

 2011/1/26 Erik Hofman e...@ehofman.com:
  On Wed, 2011-01-26 at 07:19 -0600, Jon S. Berndt wrote:
 
  I have received and applied patches from several places recently. Make
 sure
  that patches are not accidentally reversed.
 
  They won't since the patches at the FlightGear side will be overwritten
  by what JSBSim had in CVS.

 Unless I am mistaken, the plan is now to have a 2-way code exchange
 between FlightGear and JSBSim :
 FG = JSBSim for JSBSim.[ch]xx/FlightGear.[ch]xx
 JSBSim = FG for other JSBSim files.

 Who will make sure that those files are always in a consistent state ?

 Let's take an example : let's say I develop some code for JSBSim to
 take into account FG ground material in the landing gears friction
 forces. For that, I need to modify both JSBSim library *and*
 FlightGear glue code. So I will submit a patch to JSBSim (for the
 friction calcs) and another patch to FlightGear (to give JSBSim access
 to FG material data). The patch for FG glue code cannot be applied
 readily : first JSBSim needs to be patched and then copied in
 FlightGear (or otherwise FG compilation will fail). Once JSBSim last
 revision is copied in FlightGear the second part of the patch must be
 committed immediately in FlightGear (otherwise FG compilation will
 fail). And then the patched glue code will be copied back in JSBSim.
 Notice that the patch can be applied at any moment in JSBSim, even 1
 month or 1 year after its submission. On the other hand, some tight
 synchronization is needed on the FlightGear side if you don't want FG
 compilation to break. Do you think such a process is sustainable ? I
 don't.

 Cheers,

 Bertrand.


 --
 Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
 Finally, a world-class log management solution at an even better
 price-free!
 Download using promo code Free_Logger_4_Dev2Dev. Offer expires
 February 28th, so secure your free ArcSight Logger TODAY!
 http://p.sf.net/sfu/arcsight-sfd2d
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel




-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org -
http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/

Re: [Flightgear-devel] 777-200ER ground handling..

2011-01-26 Thread Heiko Schulz
Hi,


 This is for Syd really. There is
 topic on the forum about improving
 the 777 FDM, and I myself got a bit carried away with
 modifying the
 ground steering. Attached is a diff of my changes against
 git master,
 as well as a zip file containing (hopefully) all the
 modified files.
 
 What this does is:
 
 1) Limits nose gear steering by rudder to 7 degree as in
 the real aircraft.
 2) Adds tiller steering which overrides any rudder
 steering, and
 allows to steer nose gear a full 70 degree left or right
 like real
 aircraft.
 3) Adds main gear, aft axle steering that comes on when
 tiller
 steering is above 13 degrees like real aircraft. Currently
 main gear
 steering is up to 8 degrees as that is the number I found,
 but needs
 verified...
 4) Adds a tiller steering dialog which can be used to steer
 aircraft
 with the tiller...available in 777 menu. Can also map a
 spare joy axis
 to /controls/gear/tiller-cmd-norm if you have one
 available.
 
 It's a little rough around the edges, and you may want to
 change
 property names, locations, and whatever..but I thought I'd
 post it in
 case you are interested in it. Feel free to use, ignore,
 modify, etc
 however you like. :)
 
 cheers!
 

Sounds great- but do you know this already?: 
http://www.gitorious.org/syd-s-flightgear-content/777-200er

You might wanna try a merge request

Cheers
Heiko



--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] 777-200ER ground handling..

2011-01-26 Thread Jacob Burbach
On Wed, Jan 26, 2011 at 6:28 PM, Heiko Schulz aeitsch...@yahoo.de wrote:
 Sounds great- but do you know this already?: 
 http://www.gitorious.org/syd-s-flightgear-content/777-200er

 You might wanna try a merge request

 Cheers
 Heiko

Nope, I didn't know about that one. Thanks. :)

cheers
--Jacob

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] VATSIM support?

2011-01-26 Thread Chris O'Neill
On Tue, 2011-01-25 at 23:41 -0700, jac...@lfstech.com wrote:
 How about a show of hands?  Is there enough interest and volunteers to
 organize a team to tackle the problem?

As I said in my original post, I'm not a programmer so, unfortunately, I
couldn't help in that regard.  However, I'd be willing to help as an
end-user/tester.

Regards,

Chris




--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] list of aircraft that don't load in fgdata

2011-01-26 Thread dave perry

On 01/26/2011 01:31 PM, Anders Gidenstam wrote:

On Tue, 25 Jan 2011, dave perry wrote:


I have tried to load several AC that did not load with filed to load
file name errors.  So I did a survey of the entire up-to-date
fgdata.  I used an up-to-date fgrun and went through all the AC.

The following do not load even to the viewer in fgrun:
737-100, 737-300, AG-14, Airwave Xtreme 150, CRJ-200, DC-8-63, Fairchild
Metroliner, Fooker50-Denim, Jaguar, Late-29, marchetti, MIG-29 Fulcrum,
Mirage F1, North American OV-10A USAFE Bronco, Short Empire, x24b, and
Zepphelin NT07 multiplayer copilot.

Did you try them in FlightGear too?

As far as I know both Short Empire and ZLT-NT-copilot (the latter doesn't
have any visible model btw) load fine in FlightGear so if the problems
with them occur only in fgrun I'd be inclined to consider it a problem in
fgrun's model viewer rather than a problem in the aircraft.

Cheers,

Anders

Hi again,

I decided to kill a few hours today chasing down the source of the 
failure in fgrun for each AC I listed.  I can put these failures in 3 
classes.  These are the first things that fgrun rejects.  There are 
likely others.


Class 1:  fgfs and fgrun handle recursion of paths differently.

   Anders, you are correct concerning the failure of fgrun to load both
   the Short Empire and the ZLT-NT-copilot.  These as well as the
   Jaguar fail to load in fgrun because of differences in the way
   recursive paths are handled in fgrun and fgfs xml parsers.

Class 2:  Linux Windows path differences (spaces in dir and file names 
or case sensitive).


   737-300 path is .../Flightdeck/Instruments/STBY/alt.xml but file is
   ALT.xml
   AG-14path is .../Instruments/Reloj digital/Reloj digital.xml
   Fairchild Metroliner   path is .../Instruments/Marker/MarkerLights.xml
but actual path is .../Instruments/marker/MarkerLights.xml
   Mirage_F1   path is ../Models/cockpit/Divers/... but actual dir is
   divers

Class 3:  File or dir missing

   737-100  several redundant models for instruments need to be deleted
   to match actual
directory structure.  Example: 
   .../Instruments/aib/ai.xmldir aib doesn't exist

   CRJ-200   path .../fgdata/Models/Airport/Pushback/warning-light.xml
   doesn't exist
   DC-8-63 pathAircraft/dc8-63/Models/cargobox.xml/path doesn't exist
   Fokker50-Denim   path .../Models/fokker50denim.xml doesn't exist
   Fokker50-KLM   path .../Models/fokker50klm.xml doesn't exist
   Fokker50-VLM   path .../Models/fokker50vlm.xml doesn't exist
   Late-29path .../Effects/wakeG.xml,  actual path
   .../Effects/waves/wakeG.xml
   Mig-29 path .../Effects/tiptrail.xml, no Effects dir
   OV-10A USAFE   path .../Aircraft/OV10/Effects/smoke.xml, no Effects dir

The UIUC models with .mdl files don't load in fgrun viewer and don't 
seem to work from the command line either.


Case 1 needs to be addressed by the maintainers of fgrun.  Since this 
difference in parsing recursive paths only shows up for 3 of 100+ 
aircraft, it is true that this can be easily avoided by the aircraft 
maintainers.


Case 2 should be addressed by the aircraft maintainers as FlightGear is 
a cross-platform project.


Case 3 should also be addressed by the aircraft maintainers.  Some of 
this is just sloppy xml files with cruft not removed because it is not 
causing fgfs to crash or abort.  Some of this is likely work in progress.


Is it possible to add a switch to the fgfs command line so that it 
aborts when a file or directory request violates the cross-platform goal 
(names with case not matching the actual dir or file names or names with 
embedded spaces).


Cheers,
Dave P.

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] [FlightGear-devel] Rogue accounts on wiki

2011-01-26 Thread Tom P
Hi,

Just a heads up.

I always wondered why so many accounts with very suspicious names were being
created on the Wiki.
I think the answer is clear now, someone is trying to place traps for the
unwary with links pointing to rogue pages:

http://wiki.flightgear.org/index.php/Special:RecentChanges

Two examples of these traps:

http://wiki.flightgear.org/index.php/Special:RecentChanges

   - (diff | 
histhttp://wiki.flightgear.org/index.php?title=Administration_Jobs_In_Northern_Irelandcurid=6350action=history)
   . . N Administration Jobs In Northern
Irelandhttp://wiki.flightgear.org/index.php/Administration_Jobs_In_Northern_Ireland‎;
   01:35 . . *(+4,773)* . .
Prinraphttp://wiki.flightgear.org/index.php?title=User:Prinrapaction=editredlink=1

(Talkhttp://wiki.flightgear.org/index.php?title=User_talk:Prinrapaction=editredlink=1
| 
contribshttp://wiki.flightgear.org/index.php/Special:Contributions/Prinrap
   ) (Created page with . . . . . . . ==center[
   
http://esecuritys.com/SESS_kd2MjE3fHwxMjk2MDgxOTYzfHwxOTUyfHwoRU5HSU5FKSBNZWRpYVdpa2k%3D_administration%2Bjobs%2Bin%2Bnorthern%2Bireland.htmlbig...)
   - (diff | 
histhttp://wiki.flightgear.org/index.php?title=Administration_Jobs_In_Michigan_Charter_Schoolscurid=6349action=history)
   . . N Administration Jobs In Michigan Charter
Schoolshttp://wiki.flightgear.org/index.php/Administration_Jobs_In_Michigan_Charter_Schools‎;
   01:35 . . *(+4,018)* . .
Amfrweshttp://wiki.flightgear.org/index.php?title=User:Amfrwesaction=editredlink=1

(Talkhttp://wiki.flightgear.org/index.php?title=User_talk:Amfrwesaction=editredlink=1
| 
contribshttp://wiki.flightgear.org/index.php/Special:Contributions/Amfrwes
   ) (Created page with . . . . . . . ==center[
   
http://esecuritys.com/SESS_wk4MjE3fHwxMjk2MDgxOTYzfHwxOTUyfHwoRU5HSU5FKSBNZWRpYVdpa2k%3D_administration%2Bjobs%2Bin%2Bmichigan%2Bcharter%2Bschools..
   .)


  Tom
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel