OK - I just tagged fgdata, simgear and flightgear branch release/2.4.0
with the label version/2.4.0-final. This is the codebase for the 2.4.0
release.
Some off topic:
Today, Martin and I started to prepare our new simulator for road
transport. Enjoy some pics here:
http://www.c172fg.de/
22:46, schrieb Torsten Dreyer:
OK - I just tagged fgdata, simgear and flightgear branch release/2.4.0
with the label version/2.4.0-final. This is the codebase for the 2.4.0
release.
Some off topic:
Today, Martin and I started to prepare our new simulator for road
transport. Enjoy some pics
Am 17.08.2011 16:11, schrieb Curtis Olson:
Here is a quick announcement that FlightGear v2.4 is now officially
released! You can read the full announcement on the flightgear.org
http://flightgear.org web site here:
http://www.flightgear.org/announcements/flightgear-v2-4-0-released/
A huge
Aircraft (and partially Nasal) are things dependent on the core - so
naturally they can only be designed with respect to a given core state -
and that means that conceptually the core has to be fix before the
dependent stuff is fixed.
FWIW, I added a section lessons learned to the
I just merged the release/2.4.0 branches up to tag version/2.4.0-final
into the master branch of SimGear and FlightGear.
The intention for the master branch of the two code repositories is to
always hold the current version.
For consistency, I'd like to have the same strategy on fgdata sometime
Hi,
I have just pushed a little patch to SimGear to implement feature
request #372 (http://code.google.com/p/flightgear-bugs/issues/detail?id=372)
This adds some fuzzy-logic to condition elements by introducing an
optional precision element. Without the precision element the
behavior is
Am 20.09.2011 22:25, schrieb Durk Talsma:
how I can specify new property in an aircraft -set.xml file, and ensure that
any changes to this property are saved in an aircraft specific data file.
Just add this to you aircraft's nasal code so it gets executed once
during startup.
that interfere with your
existing nasal code?
Cheers,
Durk
On 20 Sep 2011, at 23:07, Torsten Dreyer wrote:
Am 20.09.2011 22:25, schrieb Durk Talsma:
how I can specify new property in an aircraft -set.xml file, and ensure
that any changes to this property are saved in an aircraft specific data
Or just:
sim
aircraft-data
path/sim/dimensions/radius-m/path
path/sim/dimensions/parkpos-offset-m/path
path/sim/aircraft-class/path
/aircraft-data
/sim
from where it's read by aircraft.nas already.
Excellent! I'm learning something
Am 06.10.2011 09:22, schrieb thorsten.i.r...@jyu.fi:
me observations I've made in the last couple of days:
* hardcoded terrain presampling: This seems to have died on me after the
last pull (probably even earlier?) - currently all I get out is zero
everywhere. Since geodinfo() is now 50 times
Am 06.10.2011 17:06, schrieb Torsten Dreyer:
Am 06.10.2011 09:22, schrieb thorsten.i.r...@jyu.fi:
me observations I've made in the last couple of days:
* hardcoded terrain presampling: This seems to have died on me after the
last pull (probably even earlier?) - currently all I get out is zero
Am 07.10.2011 09:09, schrieb thorsten.i.r...@jyu.fi:
We would like surface-wind/speed-kt, /direction-from-deg,
/velocity-from-east-fps, velocity-from-north-fps, (please not 'from
heading'
), but use whatever is easiest, we can handle the conversions easily
enough.
Torsten, does
Am 07.10.2011 11:20, schrieb Erik Hofman:
In my experience, for a happy life in open-source development, work on
what*you* *enjoy*, not what 'we' 'need'.
And sometimes it's not even clear if 'we' includes us..
'we' should add these wise statements to our developer's guide ;-)
Torsten
Um... not true. Cloud textures and models currently reside in
/Models/Weather/ and as far as I know are modified within fgdata, but are
not in the scenery database.
Yes, true, we noticed that already. Hence we'll have to leave it as it
is right now. A bit unfortunate, this would have really
Am 17.10.2011 19:10, schrieb James Turner:
It's been a month since I announced the intention, to switch all the main FG
platforms to use CMake, and to deprecate and remove the other build systems
from Git. There's been many small improvements in the Cmake files since then,
which I hope
Am 18.10.2011 18:24, schrieb Cedric Sodhi:
Next, clone the new repository of FGDATA
$ git clone git://gitorious.org/fg/fgdata-new.git fgdata
For some reason, there seems to be no ssh url available for fgdata-new
and the aircraft projects?
Torsten
Am 18.10.2011 19:30, schrieb Gijs de Rooy:
Torsten wrote:
For some reason, there seems to be no ssh url available for fgdata-new
and the aircraft projects?
There is. g...@gitorious.org:fg/fgdata-new.git
mailto:g...@gitorious.org:fg/fgdata-new.git and for the aircraft it's like
Am 18.10.2011 19:45, schrieb Gijs de Rooy:
Torsten wrote:
git clone g...@gitorious.org:fg/fgdata-new data
Make sure you don't forget .git. Use this:
git clone g...@gitorious.org:fg/fgdata-new.git
touche - I'm getting too old for this ;-)
It works now, thanks!
Torsten
Am 19.10.2011 20:45, schrieb Jacob Burbach:
Seems like most people are just banging their heads against the wall
trying to make a new system the same as the old, which is counter
productive and unfortunate. It is highly unlikely ANYONE needs every
single aircraft from git that they were
Thanks for the reply, but if you look a little
closer, I AM building simgear, SIMGEAR!, when I get
this error ;=((
Maybe it would have been better, clearer, if I had
said
Having just successfully compiled the latest
SimGear git, in Ubuntu 10.04, using the default,
which is -D
Am 27.10.2011 16:06, schrieb Melchior FRANZ:
a leader is someone who*leads*. Leadership by not leading
(and being proud of it) isn't a leadership style in my book.
There are many kinds of leadership: authoritative, cooperative, relaxed,
[..]
The trick is to pick the best for the current
Hi everybody,
after some very active weeks of development in the core and data, we are
slowly but steadily heading into the next release. This will be version
2.6.0 to be released in February 2012.
Please note that
- the next feature-freeze state will be entered on December, 17th - one
month
Am 30.11.11 15:56, schrieb Durk Talsma:
On 30 Nov 2011, at 11:29, Martin Spott wrote:
Stuart Buchanan wrote:
(For any third party reading this, Arnt's comments are not usually a
reflection of the general view of the FG community, as a perusal of the
mailing list will quickly show)
+1
+2
The other option is that I make the relevant changes in
January despite feature freeze. Or the third option is that the old
version of Local Weather gets shipped with 2.6 - the flag to do so is
still in the code.
Everything you mentioned sounds like bug fixing to me, not adding new
features.
Yeah, maybe one could do this with nasal, some educated guesswork
etc.. As long as everything is working normally, it should follow
other engine parameters and ambient air properties, I guess.
Hi Tuomas,
neither yasim nor jsbsim model TIT, unfortunately. Some nasal or
property-rules might
Hi Gijs,
here is a better solution:
there is a property valid in /environment/metar which fires the
listeners. The property is true if and only if there given metar string
is a valid metar report. The valid property will be written true every
time a new metar string is written (and parsed).
Am 13.12.2011 20:19, schrieb Curtis Olson:
Hey all,
I have a quick question for the git experts among us. I've done some
googling, but I must not have my search query phrased exactly right,
or maybe I don't quite know the right git terminology for what I want
to do. Hopefully it's simple
Certainly - git _is_ easy! (well, sometimes...)
Torsten
Am 13.12.2011 20:53, schrieb Curtis Olson:
Thanks to all who responded! Turned out to be a lot easier than I was
expecting. :-)
On Tue, Dec 13, 2011 at 1:47 PM, Anders Gidenstam
anders-...@gidenstam.org mailto:anders-...@gidenstam.org
Here are some questions:
1. Should I work from a c172p model more recent than on the website?
If so, where can I find the Aircrafts in gitorious?
2. How do I contribute? Do I learn to use git and create a branch? Do
I post the aircraft as a .zip file for someone to look at?
3. Should I
Hi all,
December, 17th has arrived everywhere on this planet. This is our magic
day for the next FlightGear version 2.6.0 to be released in just two
months time from now (February 17th, 2012).
All our new features for the next release should be in the gitorious
repositories by today and the
Am 18.12.2011 12:02, schrieb Martin Spott:
Personally I'm quite confident with FlightGear's flight dynamics, but
there's always room for improvement and if you know someone who's
flying the real one (maybe you're evn doing yourself), take a
stopwatch, pen and paper and record climb rates at
One question for the release managers: Do performance improvements such as
these count as bug fixes or features? Should we try to get this into
the 2.6.0 release,
or wait until 2.8.0?
For me, 3d clouds are currently mostly unusable. If this cures the
issue, I'd call it a fix. However, the
I prefer manually syncing and checking that the changes are valid, rather than
blindly over-riding what we've already got.
Hi Stuart,
this
-sin
-propertyaero/alpha-rad/property
-/sin
+
Agreed - that's a mistake in my checkin. I will correct it.
-Stuart
OK - one more.
function name=aero/function/velocity-induced-fps
description velocity including the propulsion induced
velocity./description
sum
propertyvelocities/u-aero-fps/property
we believe it is intentional.
the final increase in slipstream velocity (over the free stream velocity)
is 2* the increase in velocity at the actuator disk. Which is consistent
with the c172p FDM
-Stuart
Yes, its added twice to avoid the multiplication.
Ron
Ah, yes, found it in
Am 28.12.2011 16:04, schrieb thorsten.i.r...@jyu.fi:
8) Local Weather has no precipitation rendering. This is due to the fact
that the system uses its own layer altitude definition and a 3d
definition
..
Still to be fixed. I tried a workaround using negative cloud altitudes
with respect to a
It's actually surprisingly intricate. For instance, Local Weather allows
for boundary layer gusty winds. For some problems (the wave pattern) you'd
like to have the base (mean) wind at the surface, for others (windsock)
rather the actual wind that the aircraft is feeling.
I am now
Hi Geoff,
IIRC, I have sanitized the METAR string long ago and stripped the
newlines before writing the property.
Looks like it has crept back in somehow. I'll see if I can find what
happened, not sure if I can make it before the end of the year ;-)
Using the last few hours of the year, I
all your electronic devices. Thanks for flying FlightGear!
Torsten on behalf of the entire release crew.
Am 17.11.2011 23:57, schrieb Torsten Dreyer:
Hi everybody,
after some very active weeks of development in the core and data, we are
slowly but steadily heading into the next release
Am 15.01.2012 10:46, schrieb Erik Hofman:
On Sun, 2012-01-15 at 00:24 +, Pierre Mueller wrote:
-And still to my knowledge all things are frozen from FGdata at
www.gitorious.org and redistributed as new FGFS-Release!
FGFS-developers, please correct me when I'm wrong.
That's not true, GIT
Torsten Dreyer:
Hi everybody,
in less than one week we will pass the outer marker for our release of
FlightGear 2.6.0: the creation of the release branches in our git
repositories. A good time to read the final checklist:
* All features work as desired?
* All major bugs fixed?
(http
Subject says all...
Am 16.01.2012 20:41, schrieb Torsten Dreyer:
S - the outer marker is hooting, final checklist ist completed, the
gear is down and shows three green - let's go for it!
Tomorrow morning, on Jan. 17th between 06:00 and 09:00 UTC, I'll bump
the version number to 2.6.0
) and master (fgdata). If they also fix a
bug for the 2.6.0 release, please cherry-pick them into release/2.6.0
- Bug fixes that do not match the current development because
next|master have moved on go directly into release/2.6.0
Torsten
Am 17.01.2012 07:43, schrieb Torsten Dreyer:
Subject says all
Hi,
due to a bug in weather-utility.nas, the wave shader properties were
stuck at a constant value for wind-speed zero.
There was more unfortunate code in that file, so I refactored it as
xml based property rule. This is the relevant commit:
Am 19.01.2012 11:27, schrieb Emilian Huminiuc:
I had another question, could the wind vectors reported to the shader
be interpolated on a longer (10x - 20x or so) time frame, or could
they be updated only once a given time (1 minute or so)?
I ask this in an attempt to cure the fast moving
Am 19.01.2012 11:59, schrieb Torsten Dreyer:
Am 19.01.2012 11:27, schrieb Emilian Huminiuc:
I had another question, could the wind vectors reported to the shader
be interpolated on a longer (10x - 20x or so) time frame, or could
they be updated only once a given time (1 minute or so)?
I ask
I don't know what the solution should be, but I don't think the current
state of offering a configuration dialog which doesn't affect anything is
very good for a release. On the other hand, it should be clearly
recognizable that the Nasal module has to be loaded before the system
becomes
The shader scales the texture with windspeed and rotates it to get the
right orientation, but the actual rate those change is too quick to look
good, and gives the impression of very high speed, that's why I
suggested a longer interpolation time for the values passed to the
shader, and to
This reminds me a bit on Münchhausen's ride on the cannonball:
http://de-de.facebook.com/photo.php?fbid=281725951859631set=pu.281671675198392type=1theater
But it certainly looks like great fun!
Torsten
--
Try before you
So, let's add a Advanced-- button to the global weather dialog which
closes the global-weather dialog, enabled local weather and opens the
local weather dialog. In return, the local-weather dialog gets a
Basic-- button which disables local weather, closes the
local-weather-dialog and opens
Am 22.01.2012 21:27, schrieb Stuart Buchanan:
On Sun, Jan 22, 2012 at 5:34 PM, Torsten Dreyer wrote:
And I just pushed that to FGDATA. Global Weather and Local Weather
is dead. Long live Basic Weather and Advanced Weather :-)
Thanks Torsten. That looks great.
BTW, if this change is merged
Am 30.01.2012 23:57, schrieb Curtis Olson:
I want display my text *REAL BIG*
I know exactly what you mean. That started for me some years ago, too.
Newspapers, books, price tags in the supermarket - decreasing font sizes
EVERYWHERE!
Torsten
Am 31.01.2012 05:33, schrieb Geoff Carlson:
Greetings,
I am currently working with FlightGear in an academic setting,
researching flight simulators for a senior design project. My team would
like to find a way to view the environment simulation and the
instruments one might find in the
Am 31.01.2012 19:28, schrieb Curtis Olson:
However, in this case I'm actually trying to help someone with a small
project. There is a theory that if you present a message one word at a
time, with each word flashing up in the same fixed location
[..]
That sounds really interesting. Yes,
Am 31.01.2012 20:58, schrieb Curtis Olson:
The HUD is an interesting idea -- I was able to quickly build a custom
hud config and write my words individually to a property name for
display. With the HUD I can specify a font and a size, but if I scale
up the size, the font get's really
Hi Curt,
add text include=text.xml/ to you aircraft's model file, place
text.xml in the same directory as you aircraft's model file and see
hello, world! written in huge letters 20m in front of you aircraft.
Torsten
PropertyList
!-- It should have a name. Can be used for other
Hi,
i have recently added a new internal command: property-interpolate.
This exposes the SGInterpolator subsystem to bindings in xml animation
files. The SGInterpolator allows the interpolation of property values
over time and has so far been used via Nasal in aircraft.door.
For an example,
Am 06.02.2012 09:51, schrieb thorsten.i.r...@jyu.fi:
I guess my bottomline is that any code running on a per-frame basis should
be made more efficient when it can be made more efficient, regardless if
it is currently the limiting factor for someone or not, simply because it
may be the limiting
Hi all,
for our release of version 2.6.0 next week, we have a few open items on
our checklist and I am kindly asking for support to get them done:
1. How are our release candidates performing? Are there any release
blocking bugs that should be taken care of?
2. What is the state of our
Am 22.01.2012 21:27, schrieb Stuart Buchanan:
On Sun, Jan 22, 2012 at 5:34 PM, Torsten Dreyer wrote:
And I just pushed that to FGDATA. Global Weather and Local Weather
is dead. Long live Basic Weather and Advanced Weather :-)
Thanks Torsten. That looks great.
BTW, if this change is merged
The FlightGear development team is happy to announce the v2.6.0
release of FlightGear, the free, open-source flight simulator. This
new version contains many exciting new features, enhancements and
bugfixes. Major improvements from v2.4.0 include reduced AI aircraft
load times, easier
Hi,
as we are going to release version 2.6.0 this weekend, the branches
release/2.6.0 in simgear, flightgear and fgdata shall receive no more
updates after today (Thursday), 19:00 UTC until further notice to give
those who are preparing binaries and tar-balls some undisturbed time to
do their
Am 18.02.2012 01:04, schrieb Heiko Schulz:
I have created now a merge Request including the ratings of aircraft I have
been involved, I hope it is not too late.
It is :-(
Torsten
--
Virtualization Cloud Management
Am 18.02.2012 10:55, schrieb Heiko Schulz:
I have created now a merge Request including the ratings of aircraft
Ihave been involved, I hope it is not too late.
It is :-(
Of course, it's never too late to be included in the master branch,
which means that it will be part of 2.8.0 coming
Hi everybody,
just in case you havn't yet noticed yet: our release 2.6.0 is out!
This is our second scheduled release following our published
http://wiki.flightgear.org/Release_plan and we did it in time.
Thanks everybody for your support, for your contributions and for your
patience during
Am 19.02.2012 21:54, schrieb dave perry:
Hi All,
I have been gone for almost a year. I want to start new source trees
for simgear and flightgear and track on going development. Which git
branches should I check out in this new set of directories? And from
the e-mails I have read from the
Am 21.02.2012 15:32, schrieb Stefan Gofferje:
During my tinkering with Sunrises 1.1, I added the following for the
sim/ section:
systems
property-rule
nameLocal Weather Rules/name
pathEnvironment/local-weather-rules.xml/path
/property-rule
/systems
Doing so replaces
Am 22.02.2012 10:47, schrieb Stefan Gofferje:
Hm, in my preferences.xml are 2 property rules without any index. Shouldn't
they replace each other then?
Nope - this represents an entire tree and so end up implicitly with
/sim/systems/property-rule[0]/
/sim/systems/property-rule[1]/
By adding
Am 24.02.2012 01:17, schrieb St
The end result is that I'd like to do the following:
- Create a new Materials directory under fgdata
- Move materials-dds.xml and materials.xml into it
- Create a new Materials/materials-base.xml file containing material
definitions common
to both materials
Am 28.02.2012 10:11, schrieb Stuart Buchanan:
On Tue, Feb 28, 2012 at 12:27 AM, Curtis Olson wrote:
Interesting -- if smoke is also going the wrong way, maybe a bug was
recently introduced with wind/environment?
I recall a big change to a lot of vector classes quite a while ago,
possible
Looks like we have two bugs here:
1. wind turbines with mixed orientations. These should be fixed in the
database. If the correct orientation in the stg file is zero.
1a. wind turbine orientation and rotation/spin speed is bound to
/environment/wind-from-heading-deg and
Am 29.02.2012 12:25, schrieb thorsten.i.r...@jyu.fi:
Wind turbines are probably too heavy to swing with the gusts in any
significant way.
Hehe - yes.
Drag chute of the English Electric Lightining was also displayed blown
into the wind at some point - might be related?
That should be an
Am 29.02.2012 13:05, schrieb Erik Hofman:
On Wed, 2012-02-29 at 11:43 +0100, Torsten Dreyer wrote:
Looks like we have two bugs here:
1. wind turbines with mixed orientations. These should be fixed in the
database. If the correct orientation in the stg file is zero.
I was wondering, shouldn't
Am 02.03.2012 19:03, schrieb Frederic Bouvier:
Now that release 2.6 is out, perhaps it is time to discuss further
developments concerning project Rembrandt.
Although it may already produce pretty images when used by a talented
designer (see for example the P92), it is however, not usable by
Is there any chance to make Rembrandt switchable (on/off) at startup?
That should be doable, but not done for the moment. Changes are located
in CameraGroup.[ch]xx and Renderer.cxx for the flightgear side, in
sgmaterial.lib for the simgear side and in Effects/ and Shaders/ for the
data side,
Am 03.03.2012 12:33, schrieb Frederic Bouvier:
But just curious : how many of you reviewed the current code ?
n+1
Just checked out your project/rembrandt branches. Code compiles fine on
64bit openSUSE 12.1 with OSG from trunk.
Running fgfs spits out many messages, most prominent are:
can't
Hi Fred,
today, I tried Rembrandt on two Linux machines, both running 64bit
openSUSE 12.1 (this is Linux) with nvidia'd driver 295.20.
FlightGear ist started in windows mode.
1.) My Notebook having a Intel dual core@1.6GHz, 4GB RAM and a GeForce
Go 7400 with 256MB RAM.
FlightGear starts, after
Am 07.03.2012 18:14, schrieb Roberto Inzerillo:
Hi everybody,
it's a few weeks I'm dealing with a few analog to digital converters, I'm
using them to convert external analog signals and use them as inputs to
FlightGear controls.
I'm wondering which resolution is best when dealing with
Am 07.03.2012 20:59, schrieb Roberto Inzerillo:
I'm not talking about what people are currently doing (I'd go with 24bit
on everything ... joking!), I'm asking about reasons (technical aspects,
facts) that can help me decide for high-res against low-res.
That would help me a lot in making good
Am 08.03.2012 08:27, schrieb thorsten.i.r...@jyu.fi:
I still have two small (weather-related) issues which I can't resolve myself:
* rain is still 'smart' i.e. de-activates above the lowest cloud layer.
Since Advanced Weather has its own precipitation region control, I'd need
a dumb version
Am 09.03.2012 07:51, schrieb syd adams:
On Thu, Mar 8, 2012 at 10:19 PM, Curtis Olsoncurtol...@gmail.com wrote:
Hi Syd,
That was a hack from the very early days of the project, so if it went away,
it wouldn't bother me. Fred might have a check box in the window launcher,
and there may be a
Am 08.03.2012 19:43, schrieb ThorstenB:
On 08.03.2012 19:21, Curtis Olson wrote:
I bet there's a line of code somewhere that looks like:
if ( visibility_meter 1000 ) {
do_sky_dome_stuff();
}
Ha, Curt, I know you cheated! You just looked at the code, right? ;-)
Am 09.03.2012 20:57, schrieb Renk Thorsten:
Ok I haven't entirely given up on the idea of removing the
auto-coordination from the code.
Why?
Wouldn't it be more appropriate to add
that rudder control to controls.nas?
Nasal runs per graphical frame, FDMs may need to run faster at low
Am 09.03.2012 20:44, schrieb syd adams:
Ok I haven't entirely given up on the idea of removing the
auto-coordination from the code.Wouldn't it be more appropriate to add
that rudder control to controls.nas?
Then it can be replaced if need be on a per aircraft basis , but not
break anything
This is in fact my preferred solution.
- it does not break existing aircraft
- it keeps existing --enable-auto-coordination behavior
- it is configurable, even at runtime
- minimal code change
I have the patch ready and I'm about to commit it. While at it, I'd like
to move the involved
Hi Fred Thorsten,
I just noticed, that the Sunrises 1.2 commit reverted a change to
environment.xml, I have commited two weeks before. That's not a big
issue, changing that back was just a one-line change.
To help avoiding unintended changes, could you please consider joining
our regular
Am 12.03.2012 18:25, schrieb andrea...@gmx.net:
Hi, I'm the one who asked about the legal situation of using elevation
data from a topographic map.
http://www.flightgear.org/forums/viewtopic.php?f=5t=15711p=152972sid=0383829e2324ecb1bc0c0ed67655e826#p152945
I checked with the institution
Hi Syd,
This is now in git:
The auto-coordination and auto-coordination-factor properties now live
in /controls/flight. A backward compatibility check in aircraft.nas
checks if somebody created /sim/auto-coordination and if so, spits out
a warning messages and makes this property an alias
Hi Andres,
thanks for pointing these out. We have been chasing and replacing
(s)(n)printfs in our code over the years but not at a high priority.
Everytime I (and others) are working on a file and stumble upon a
printf, we try to replace this with more robust code.
This is low priority,
The cost of shadows is the difference in fps between night and day, as
shadow rendering is disabled at night.
No moon shadows? I see a long discussion coming up about how unrealistic
this all is ;-)
Torsten
--
Am 03.04.2012 18:02, schrieb Gene Buckle:
On Tue, 3 Apr 2012, Martin Spott wrote:
Stuart Buchanan wrote:
How's the cockpit project going BTW?
Having a sponsor to pay the transport would be cool ;-)
Aside from that, we're looking for a couple of small (8-12 range),
bright and preferrably
Hi,
what is our current policy for updates to nav.dat? Do we commit changes
to the binary gzip'ed file or do we have a central repository for the data?
Would it make sense to have the unzip'ed file in git and zip it for the
release in make dist?
Torsten
Hi,
in just a bit more than two weeks from now we reach June, 17th, marking
the first milestone for the release of next FlightGear version: the
feature freeze period.
If you have some great and exciting new features for FlightGear on your
local disc but not yet pushed the gitorious
winter's aircraft commit policy (no feature freeze) for all
aircraft but the base package's A/C selection.
Is that consensus?
Greetings,
Torsten
Am 02.06.2012 21:36, schrieb Torsten Dreyer:
Hi,
in just a bit more than two weeks from now we reach June, 17th, marking
the first milestone
Hi everybody,
today is June, 17th and this marks our feature freeze for the sources of
SimGear, FlightGear and FGDATA. Within FGDATA, only aircraft not being
part of the base package are not part of the feature freeze. Maintainers
for those aircraft are kindly requested to carefully check not
I'd like to change our CAVOK definitions to no cloud and 15km
visibility. That way those of us using real weather fetch as a matter
of course might occasionally get gin clear skies without a cloud in
the sky. Unlike the UK summer this year...
Any objections?
No objections but an idea: how
No objections but an idea: how about adding a little randomness to the
cloud cover and visibility?
Good idea, but I'm not surely exactly how to go about it while retaining
some element of determinism. I'm worried about multi-computer systems,
or two users at the same airport in the MP
Hi everybody,
we are very close to our release date, just a few days left until we
hopefully ship our latest-and-greates-ever FlightGear version.
Please check the changelog at http://wiki.flightgear.org/Changelog_2.8.0
and make sure every new feature is noted at a prominent place there.
These
Hi all,
I have just suggested off-list to close the release/2.8.0 branches
(FG+SG+FGDATA) on Thursday (16th) in the morning (UTC) to give those
packing the binaries and tarballs enough time for the task.
Please shout if there are any objections.
Thanks
Torsten
Am 14.08.2012 16:06, schrieb Tim Moore:
On Tue, Aug 14, 2012 at 3:40 PM, Curtis Olson curtol...@gmail.com wrote:
On Tue, Aug 14, 2012 at 3:30 AM, Torsten Dreyer tors...@t3r.de wrote:
Hi all,
I have just suggested off-list to close the release/2.8.0 branches
(FG+SG+FGDATA) on Thursday (16th
601 - 700 of 747 matches
Mail list logo
