David Luff wrote:
Hi folks,
I've added a KLN89 GPS unit hardcoded in C++ (OK'd by Curt).
Well, I object. How could I tell others to postpone their contribution
until after the release of FlightGear 1.0 if you are allowed to add this
rather comprehensive peace of code?
Erik
* Erik Hofman -- Wednesday 30 November 2005 09:56:
How could I tell others to postpone their contribution until after the
release of FlightGear 1.0 [...]
Good question, indeed! How could you? There was no discussion about
this topic on flightgear-devel before this order was announced, and
every
On Tue, 2005-11-29 at 16:52, Curtis L. Olson wrote:
Steve Hosgood wrote:
Is it planned that after 1.0.0, there will be a 'development' tree of
1.1.x, with the next proper release becoming 1.2.x?
For what it's worth, we did use this version numbering
scheme for a while. Officially 0.8.0 is
Well, I object. How could I tell others to postpone their contribution
until after the release of FlightGear 1.0 if you are allowed to add this
rather comprehensive peace of code?
What about labelling the fg tree with your own 1.0 pre-release label?
And branching off it, only merging in the
--- Vassilii Khachaturov wrote:
What about labelling the fg tree with your own 1.0 pre-release label?
And branching off it, only merging in the trunk changes
that you see fit?
I think this might result in the v1.0 release withering on the branch so
to speak ;). Everyone would probably just
Melchior FRANZ wrote:
Good question, indeed! How could you? There was no discussion about
this topic on flightgear-devel before this order was announced, and
every discussion after that was passively suppressed by ignoring valid
arguments. How was this decision made and by whom? Is FlightGear
Steve Hosgood wrote:
But you could consider that after 1.0.0 things will change - if you make
it so. Have a rule that the only tarballs and other packages on the
FlightGear website are of the even subtree. Anyone wanting odd subtree
stuff must go to the CVS for it. Make sure that the even
Buchanan, Stuart wrote:
--- Vassilii Khachaturov wrote:
What about labelling the fg tree with your own 1.0 pre-release label?
And branching off it, only merging in the trunk changes
that you see fit?
I think this might result in the v1.0 release withering on the branch so
to speak
Stefan Seifert wrote:
Why the need for an odd subtree then?
Normal end users use the released packages on the webpage (currently
0.9.9). Everyone else, including developers and bleeding edge people
already check out from CVS.
One could branch the 1.0 tree in CVS and provide small fixes on
Stefan Seifert wrote:
Why the need for an odd subtree then?
Normal end users use the released packages on the webpage (currently
0.9.9). Everyone else, including developers and bleeding edge people
already check out from CVS.
One could branch the 1.0 tree in CVS and provide small fixes on
Erik Hofman wrote:
Well, I object. How could I tell others to postpone their contribution
until after the release of FlightGear 1.0 if you are allowed to add
this rather comprehensive peace of code?
This is a fair point to make ...
1. Let me say though that this code was ready to go before
Melchior FRANZ wrote:
* Erik Hofman -- Wednesday 30 November 2005 09:56:
How could I tell others to postpone their contribution until after the
release of FlightGear 1.0 [...]
Good question, indeed! How could you? There was no discussion about
this topic on flightgear-devel before
For example I'd strongly consider the missing options saving a bug that
has to be fixed before we give FlightGear to all the people out there.
They are used to this behavior from nearly every program they use, and
will expect the same from FG. Others may think, that we lived without
this
On Wed, 2005-11-30 at 12:46, Curtis L. Olson wrote:
Stefan Seifert wrote:
Why the need for an odd subtree then?
Normal end users use the released packages on the webpage (currently
0.9.9). Everyone else, including developers and bleeding edge people
already check out from CVS.
Vassilii Khachaturov wrote:
For example I'd strongly consider the missing options saving a bug that
has to be fixed before we give FlightGear to all the people out there.
They are used to this behavior from nearly every program they use, and
will expect the same from FG. Others may think, that
Right now I suspect that most users of FG are either developers or
bleeding edge people. But the idea is that that should start changing as
of 1.0.0. Indeed - that's *why* there's a 1.0.0, surely?
FYI: I had been on and off subscribing the fg lists and basically just
the Debian stable package
* Curtis L. Olson -- Wednesday 30 November 2005 14:01:
Melchior FRANZ wrote:
There was no discussion about this topic on flightgear-devel before
this order was announced, and every discussion after that was passively
suppressed by ignoring valid arguments. [...]
I don't want to passively
Curtis L. Olson wrote:
Vassilii Khachaturov wrote:
For example I'd strongly consider the missing options saving a bug that
has to be fixed before we give FlightGear to all the people out there.
They are used to this behavior from nearly every program they use, and
will expect the same from FG.
* Curtis L. Olson -- Wednesday 30 November 2005 15:19:
You may want to attack this in small steps ... for instance start out
with just getting save/load of aircraft position working.
As demonstrated before [1], this is quite easy to do even
with Nasal[2]. The only thing that needs to be
(I don't give a hoo about patch politics and version number
supersticion.)
I'm curious about the choice of language/linkage for the implementation:
Why have a specific vendor model hard-coded in c++? Seems more like task
for xml/nasal scripts to me. ?:-P Nothing wrong with the language (c++)
Melchior FRANZ wrote:
As demonstrated before [1], this is quite easy to do even
with Nasal[2]. The only thing that needs to be implemented in fgfs
is a way to tell it where to store the files. Something like
FG_HOME/--fg-home. Paul was already working on that for exactly
this purpose[3], but
Hello Curt,
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/Rascal
In directory baron:/tmp/cvs-serv29111
Added Files:
README.Rascal Rascal110-set.xml Rascal110.xml
rascal-electrical.xml thumbnail.jpg
[...]
flight-modelyasim/flight-model
Martin Spott wrote:
I'm very much surprised to see that you intend to use YASim for an
aircraft, that you want to model based on existing flight data.
Do you actually expect YASim to be the right tool for that job or is it
simply leftover from using the Cub layout as basis ? I might miss the
Folks, was there a bug in the autopilot on the c172 default airplane in
0.9.8?
I fill in the fields and tick the boxes on the Autopilot dialog box,
take my hands off the stick and the bloody thing wanders all over the
sky.
1) Maybe this is an accurate model of the c172 autopilot? :-)
or
2)
Steve Hosgood wrote:
3) It was broken in 0.9.8 but is fixed now. I *think* I may have tried
it in 0.9.9 with the same results. Not sure. Can't check right now.
It'll still be the same. The C172 doesn't use the generic autopilot code
- it has a KAP140 autopilot model - which is controlled by
Steve Hosgood wrote:
It may not be universally true, but quite a few projects only start
the even/odd numbering scheme *after* they've got as far as 1.0.0
My $0.02 is that we don't want to bother with this. The purpose to
having a stable release is that third parties can build on the
product
-- Steve Hosgood wrote:
Folks, was there a bug in the autopilot on the c172 default airplane in
0.9.8?
I fill in the fields and tick the boxes on the Autopilot dialog box,
take my hands off the stick and the bloody thing wanders all over the
sky.
IIRC the C172p uses the KAP140 (or
On Wednesday 30 November 2005 17:34, Steve Hosgood wrote:
or
2) Maybe the c172 doesn't have an autopilot.
It has an autopilot, but you operate it with buttons on the panel, you know,
like in Real-Life[TM].
If the latter, then surely the dialog box ought not to be available (i.e
be greyed
* Roy Vegard Ovesen -- Wednesday 30 November 2005 18:16:
Is this possible, Melchior, to disable the autopilot menu entry just for the
C172?
Not currently, AFAIK. Wouldn't be hard to add. One would probably
do that as an fgcommand() that enables/disables menu entries.
Generally, making such
--- Roy Vegard Ovesen wrote:
If the latter, then surely the dialog box ought not to be available
(i.e
be greyed out in the relevant menu).
Is this possible, Melchior, to disable the autopilot menu entry just for
the
C172?
Thanks the Melchior's XML menu changes, I would think the
Simon Hollier wrote:
Hello,
Attached is a patch for flightgear and simgear that removes the
model_panel kludge and fixes a potential memory leak.
Thoughts/comments?
Simon
I can not test the patch due to lack of time, but I have the impression
that this is not backward
compatible with the
Releasing flares on the f16 did not work anymore. Thanks to Joacim and
vivian we have a cure for this.
Patch attached.
Nine
Index: f16-set.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/f16/f16-set.xml,v
retrieving
Could be added to the list of admitted features for 1.0, next
to landing lights ... :-)
Agreed. Esp. because this is mostly a gui XML / trivial NASAL thing.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
On Wednesday 30 November 2005 16:50, Melchior FRANZ wrote:
* Curtis L. Olson -- Wednesday 30 November 2005 15:19:
You may want to attack this in small steps ... for instance start out
with just getting save/load of aircraft position working.
As demonstrated before [1], this is quite easy to
On Wed, 30 Nov 2005 11:29:12 -0600, you wrote:
It'll still be the same. The C172 doesn't use the generic autopilot code
- it has a KAP140 autopilot model - which is controlled by clicking the
buttons on the device in the cockpit.
This confusion will raise its head every time a person comes to
On Dienstag 29 November 2005 22:21, Vassilii Khachaturov wrote:
Just to aid the investigation/possible fixing:
in case you missed it, a similar crash (ground-minding models)/teleport to
hell (ufo) happens in a slightly different scenario I had reported --
see
Stefan Seifert wrote:
The scope I thought about is actually not really difficult to reach. I
do just want to make changes a user makes in the option dialogs
(rendering options, level of detail, sound volume, maybe others)
persistent. For this I changed SGProperty node to include a new
On Wed, 30 Nov 2005 00:49:14 -0600, you wrote:
Of course - which is where the Wiki comes in as I see it. Up to date
information that's very easily kept that way... Not a replacement for the
conventional docs, but I do feel the link on the FG website could be slightly
more prominent - even
On Wed, 30 Nov 2005 00:49:14 -0600, you wrote:
I've added a KLN89 GPS unit hardcoded in C++ (OK'd by Curt). Briefly, since
it's late, it's only included on the c172p 2D panel
(--aircraft=c172p-2dpanel). It looks best at --geometry=1024x768 since the
fonts are at 1:1 pixellation at that
Steve Knoblock wrote:
I'm not sure if it is possible or reasonable to implement a moving
map GPS display in NASAL and instrument XML, however, a simple text
display might be feasible.
Probably not, but you might still want to script some of the
functionality -- especially for complicated
Simon Hollier wrote:
Hello,
Attached is a patch for flightgear and simgear that removes the
model_panel kludge and fixes a potential memory leak.
Thoughts/comments?
Simon
I can not test the patch due to lack of time, but I have the impression
that this is not backward
compatible with the
Andy Ross schrieb:
Steve Knoblock wrote:
1. Will Nasal scripting give me all options to program the
push-back function (incl. playing sound files and checking
distances to other planes or to next taxi way)?
I am not sure of this, but NASAL can listen for properties and then
David Luff [EMAIL PROTECTED] writes:
I've added a KLN89 GPS unit hardcoded in C++ (OK'd by Curt).
Briefly, since it's late, it's only included on the c172p 2D panel
(--aircraft=c172p-2dpanel). It looks best at --geometry=1024x768
since the fonts are at 1:1 pixellation at that resolution.
the
Martin Spott wrote:
I'm very much surprised to see that you intend to use YASim for an
aircraft, that you want to model based on existing flight data.
Do you actually expect YASim to be the right tool for that job or is it
simply leftover from using the Cub layout as basis ? I might miss the
Steve Knoblock writes:
Now that we are seeing a choice of GPS units, it beings to raise a
similar question to the autopilot. There will be confusion over the
waypoint and gps dialogs on the FG toolbar. It may be necessary to do
something similar as I proposed with autopilot.
Yes, I agree
Joacim Persson writes:
I'm curious about the choice of language/linkage for the implementation:
Why have a specific vendor model hard-coded in c++? Seems more like task
for xml/nasal scripts to me. ?:-P Nothing wrong with the language (c++)
but isn't it a little out of place in the fgfs
Alex Romosan writes:
David Luff [EMAIL PROTECTED] writes:
Urgghh - email addy in header!
I've added a KLN89 GPS unit hardcoded in C++ (OK'd by Curt).
Briefly, since it's late, it's only included on the c172p 2D panel
(--aircraft=c172p-2dpanel). It looks best at --geometry=1024x768
David Luff [EMAIL PROTECTED] wrote:
Alex Romosan writes:
David Luff [EMAIL PROTECTED] writes:
Urgghh - email addy in header!
And from an unexpected source, too:
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)
Someone needs to plonk the emacs folks, methinks. :)
Andy
On Nov 30, 2005, at 4:46 PM, David Luff wrote:
Joacim Persson writes:
I'm curious about the choice of language/linkage for the
implementation:
Why have a specific vendor model hard-coded in c++? Seems more
like task
for xml/nasal scripts to me. ?:-P Nothing wrong with the language
On November 26, 2005 10:50 pm, Ampere K. Hardraade wrote:
I finally managed to compile Xorg from source today and managed to get more
information from gdb. I have also filed a bug report with Xorg:
https://bugs.freedesktop.org/show_bug.cgi?id=5142
Ampere
Ampere K. Hardraade wrote:
On November 26, 2005 10:50 pm, Ampere K. Hardraade wrote:
I finally managed to compile Xorg from source today and managed to get more
information from gdb. I have also filed a bug report with Xorg:
https://bugs.freedesktop.org/show_bug.cgi?id=5142
Ampere
On Thu, 1 Dec 2005, David Luff wrote:
I have no experience of plugin architectures, and don't feel competent to
attempt it at the moment.
First of all: there's obviously no panic. (If there were fifty-seven
hard-linked GPS models, AP's etc it would be a problem, ;)
I don't know in detail how
On Wed, 30 Nov 2005, Adam Dershowitz wrote:
However if people each develop a plugin that only works on their
personal development machine it will complicate things.
Hm. Yes. But the same fault (writing non-portable code) could be done under
ordinary static linking too. It would be noticed
Hi,
I'm glad to report that I am an idiot and that there is nothing wrong
with the data transmission code. It works fine except
when trying to write throttle over udp.
For some wierd reason it takes values of one or zero at random when
the throttle is pushed from 0 to 1. For
David Luff writes:
Alex Romosan writes:
David Luff [EMAIL PROTECTED] writes:
Urgghh - email addy in header!
sorry. if anybody knows how to change the citation line in gnus
automatically please let me know. thanks.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and
55 matches
Mail list logo
