Do we have a volunteer (Thorsten?) to tag the branches as 2.8.0 to mark the
official close of changes for 2.8.0(.0)?
You might want to wait until you cut the release before laying down the
tag...
for 2.4.0 and 2.6.0, we set the tag version/2.x.0-final. I'll set the
tag version/2.8.0-final
Hi,
for the third time in a row, we were able to release a new version of
FlightGear in time and following our Release Plan. After v2.4.0 exactly
one year ago and v2.6.0 in February, FlightGear 2.8.0 has been released
today!
The Windows installers and the source and data tarballs are
Computing constant values at runtime is bad design and we should not do
that. No matter if we notice a significant increase in load time now or
not. The ground elevation at a specific point is well known at scenery
generation time and that is where the vertical position of an object has
to be
Am 30.08.2012 03:51, schrieb castle...@comcast.net:
Hi,
Is it possible to specify gear up and down transit times for each gear?
In real airplanes the gear never ( well rarely, maybe ) sequence in
perfect unison. In reviewing the xml files for the 737, I note there
are transit times defined
Looks like the dialog is GPL and the screenshot image is CC.
Torsten--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers
Hi all,
there is a WIKI page for this topic:
http://wiki.flightgear.org/FlightGear_Git:_splitting_fgdata
Many points have been discussed over and over some time ago.
If there is something new that has developed over time, please add it to
the wiki page before it gets lost on the mailing list.
Am 06.11.2012 22:16, schrieb Durk Talsma:
Yes, I also talked to Martin Crompton. James told me later on that you had
been in touch with him. My action was rather spontaneous, so I asked him
whether we could try to support Saitek products, without me knowing that you
were also working on it.
Am 08.11.2012 23:24, schrieb Stuart Buchanan:
I'm confused. From my reading of Durk's post, 3D clouds would appear to work
fine for a multi-display system out-of-the-box, but your comment
here indicates
that there is an issue that requires fixing by restricting the random seed.
Hi Stuart,
Hi,
in just about one month from now we are entering another round of the
release process, starting with the four weeks feature freeze period.
This is probably a good time to check in all the great and fancy new
features that still hide in your local branches. I'd also like to see
JSBSim
All in all, for my part it seems rather a 2.10 than a 3.0 - some of
the things which I'd like to see in 3.0 are done, but the majority
isn't yet.
This is probably true.
To get to the 3.0 goal sometime in the near future, it's probably a good
idea to create a backlog of open items
Hi,
let me chime in here with a personal note, hoping it's not offending
anybody.
Although I like having accurate and detailed computation of our
real-world simulation, I'm not really a friend of the radio propagation
code with the level of detail given. Please let me explain why that is
the
I'd be grateful for an update of the Dragonfly and the ogeL. The
Dragonfly's configuration was a wild guess, and only very vaguely based
on real numbers. ogeL's engine is by definition just fantasy ;-)
Thanks,
Torsten
Am 08.12.2012 20:12, schrieb Ron Jensen:
I took a quick look through the
Am 22.11.2012 20:44, schrieb ThorstenB:
On 22.11.2012 10:08, Adrian Musceac wrote:
I've gone ahead and used the new radio code for navaids, but I have a
question: which navradio code is considered standard? newnavradio or
navradio?
navradio is the current/old standard, newnavradio is the
Hi
replying to multiple posts here, I'll try to collect and answer to some
arguments.
First: I totally agree that our current nav/comm radio implementation is
far from being realistic w.r.t. propagation of the radio signal close to
or on the ground. This should be improved.
I spent an hour
Hi Adrian,
you are doing an excellent job at marketing your product ;-)
As I do not have the time to proof you wrong, you deserve the chance to
proof me wrong! I'll shut up now and stop objecting against merging your
code. I won't be able to merge it myself before we enter the feature
freeze
Am 13.12.2012 16:28, schrieb geneb:
Um, no he's not. He just happens to be a contributor like the rest of us.
:) There is no herder for the Free Range Cats that make up the FlightGear
project. :)
How disappointing ;-)
Frankly, I think your addition to FlightGear is fantastic and a needed
Hi everybody,
I just had the chance to compile a recent git-pull on my old and
battered linux-notebook workhorse and with great delight, I noticed that
I can run FlightGear again with 26fps at KSFO. I had to strip down most
eye candy shaders for the GeForce Go 7400 but 3D clouds render fine
Hi,
just a short reminder: The feature freeze for the next release is
active. For those who are not familiar with our release plan
(http://wiki.flightgear.org/Release_Plan):
No new features or major changes shall be pushed onto the development
streams (neither source nor data). This period is
I have just pushed the new version number 2.10 to simgear, flightgear
and fgdata along with the tag version/2.10.0 for all three repos.
Make sure you pull all three repositories to avoid a version conflict.
After the creation of the release branches on Jan., 17th the version
numbers will again
Hi JSBSim and FlightGear lists,
should we sync the latest JSBSim code into FlightGear for the next
release, scheduled for February this year?
If so, please do this very soon so there is some time to rule out any
oddities before I create the release branches on January, 17th.
Thanks, Torsten
Am 13.01.2013 20:33, schrieb Stuart Buchanan:
On Sun, Jan 6, 2013 at 11:35 AM, Torsten Dreye wrote:
Hi JSBSim and FlightGear lists,
should we sync the latest JSBSim code into FlightGear for the next
release, scheduled for February this year?
My vote is not to sync at this point.
I'd
I had hoped that we could do this a couple of months ago, but not synching
JSBSim with the latest FlightGear would be very, very unfortunate. I'm not
sure when the last sync occurred (does anyone know?), but there have been
a lot of new features and bug fixes. Development has been very active.
Am 14.01.2013 03:57, schrieb Jon S. Berndt:
Outerra will be more up to date than FlightGear with respect to JSBSim.
It's hard to be the best all the times ;-)
Torsten
--
Master Visual Studio, SharePoint, SQL, ASP.NET,
Hi all,
today is the 17th of January and I am going to create the release
branches now
.
Please stay clear of the active runway and don't push anything to
FlightGear, SimGear and FGDATA on gitorious.
I'll post a message when I'm done.
Those, who are involved in the creation of release
Am 17.01.2013 19:03, schrieb Torsten Dreyer:
I'll post a message when I'm done.
Done.
Version 2.10.0 now lives on the release/2.10.0 branches on SimGear,
FlightGear and FGDATA to be released around the 17th of February.
SimGear and FlightGear next branches as well as FGDATA master branch
Hi,
I have just synced the latest and greatest JSBSim into FlightGear.
I flew a quick pattern with the SenecaII (the only JSBSim aircraft, I
have a rating for) and found no quirks.
Please check, if everything is still working in more complex aircraft.
Greetings,
Torsten
Any chance to wrap this into something like
if( true == getprop(/sim/use-ati-hack) ) {
addTheEmptyPrerenderCamera();
} else {
doNothing();
}
Am 28.01.2013 18:56, schrieb James Turner:
http://code.google.com/p/flightgear-bugs/issues/detail?id=385
Is about a problem with the viewport
Done.
Am 29.01.2013 22:55, schrieb Stuart Buchanan:
Hi All,
I've just pushed a small commit checking in new versions of the FG
Short Reference, something I should have done with the updated Manual
a while back.
If someone could cherry-pick the commit into the release branch, that
would be
Didn't he say GiB? And CDs are an ancient technology...
Thanks for building the RC. We need to get this automated some day. Or
at least documented...
(another one from famous last words: if you have to do it more than
once, automate it. If you can't automate it, document it.)
Torsten
Am
Hi all
unless we don't have any major release blockers, we are going to release
version 2.10 during the next weekend.
So, if there is anything still overlooked, please shout out now.
Do we have the latest getstart.pdf compiled and picked into the release
branch?
Anything else to think about?
Hi all,
at one point during every ILS approach you reach the decision altitude
with two options: continue approach or go around. Being the copilot
on our approach into the 2.10 release, I'd call out minimum, approach
lights in sight, continue!
If no one shouts out loudly _NOW_, I'm going to
Am 15.02.2013 16:16, schrieb Torsten Dreyer:
If no one shouts out loudly _NOW_, I'm going to tag the release branches
tomorrow (Saturday) morning (Central European Time) and give the package
managers the GO to build and distribute the bundles. That should give us
a ready-to-download release
Hy Yves
Sorry, I do not understand your question. Could you clarify, please?
Torsten
Am 16.02.2013 00:17, schrieb ys:
Hi Torsten
What does mean no public answer in this list for this decision ?
-Yves
Am 15.02.2013 um 16:16 schrieb Torsten Dreyer tors...@t3r.de:
Hi all,
at one point
To my knowledge, this is a fully automated task, which is croned at each
update. So for the online stuff everything seems to be fine.
The only thing I do not know is who is taking care to update the
getstart.pdf files pushed into the installers and tarballs for the release.
Ah, good news. I
Am 28.02.2013 16:38, schrieb Curtis Olson:
We've always been able to set the individual weather parameters, either
through the built in weather dialog box, or by setting raw property
values. Setting raw property values allows nasal script control over
the weather (as I'm sure you well know)
Hi everybody,
for most of us, it's June, 17th which marks the day for the feature
freeze period, lasting until July, 17th.
Everybody is invited to walk through the lessons learned section of our
release plan at
http://wiki.flightgear.org/Release_plan
the bugtracker at
snip
I apologize for missing the point.
No need to apoligize at all.
If anybody is annoying somebody, it's me with my scheduled emails about
release deadlines, my requests for following a specific release
procedure and for raising discussions about version numbers.
Some time ago, we agreed on
Hi,
I'm failing to build SimGear on 64bit linux:
EffectGeode.cxx:83:136: error: no matching function for call to
‘osg::Geometry::setVertexAttribArray(int, osg::Geometry::ArrayData)’
OSG is stable 3.0.1 from svn (same with OSG trunk)
SimGear is git next from today
Yes, I rm-rf'ed previous
Am 27.06.2013 09:58, schrieb James Turner:
On 26 Jun 2013, at 23:05, Thomas Geymayer tom...@gmail.com
mailto:tom...@gmail.com wrote:
Thank you Alex! I've just commited your patch.
Yes thank indeed Alex, it's a relief to know someone is keeping
bleeding-edge OSG working, since the rate of
Am 26.06.2013 09:58, schrieb James Turner:
Yep, works for me too.
James
Thanks, Stuart for finding a solution.
I have just pushed the version number 2.12.0 to SG, FG and FGDATA.
Torsten
--
This SF.net email is
Post a diff or the modified files or a link to a tarball here and I'll
have a look.
Probably a good start for me to get back into the loop after almost two
years of absence...
Torsten
Am 26.07.2013 21:11, schrieb Alan Teeder:
I have added a washout/high-pass filter and an integrator to the
like
typelow-pass/type or typehigh-pass/type. That would not double
existing code.
* What is the purpose for adding alias names for existing filters?
Cheers,
Torsten
Am 27.07.2013 10:27, schrieb Alan Teeder:
*From:* Torsten Dreyer mailto:tors...@t3r.de
*Sent:* Saturday, July 27, 2013 8:47 AM
Hi Tomash
the navradio code is far from being perfect and and least to attempts
for improvements exist.
Unfortunately, both have currently stalled due to several reasons.
The first is in newnavradio which you can use by setting
use-new-navradio type=boolfalse/use-new-navradio in your aircraft
, or
it computes magnetic variation on the fly?
Do we need to track magnetic variation change every year and manually
edit nav.dat for it?
2013/8/5 Torsten Dreyer tors...@t3r.de mailto:tors...@t3r.de
Hi Tomash
the navradio code is far from being perfect and and least to
attempts
Permission granted ;-)
As everybody seems to be caught in some real life trouble, I can't see a
better way to get the release out than delaying it for a while.
Would two weeks be enough for everybody? That will get us to the weekend
Aug, 31/Sep 1.
Torsten
Am 13.08.2013 16:56, schrieb
Good news, indeed and kudos to Virgin Media!
Curt and James, what would you think about publishing the release during
the weekend
Sept. 14./15.? Or would you prefer to stick to the 17th (a Tuesday)?
Torsten
Am 15.08.2013 09:21, schrieb James Turner:
On 14 Aug 2013, at 21:57, Curtis Olson
Hi all,
the implementation of the autopilot filter moving-average has changed.
Actually, the previous implementation gave incorrect results and this
bug has now been fixed in the next branch.
A quick grep through the Aircraft folder came up with
A-10, B-52F, AN-2225 and MiG-15 using the
701 - 747 of 747 matches
Mail list logo