[Flightgear-devel] Heads up: A-10, B-52F, AN-2225 and MiG-15 and users of moving-average filter

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 moving

Re: [Flightgear-devel] Release candidates

Am 28.08.2013 17:10, schrieb James Turner: > Hello, > > After fixing a dumb mistake of mine, we now have automatically generated > installers / files for Linux, Mac and Windows. > > Get them from here: (updated automatically) > > http://fgfs.goneabitbursar.com/releases/ > > WOW - that is fan

Re: [Flightgear-devel] New release date for 2.12

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

Re: [Flightgear-devel] 2.12 is branched

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 Curti

Re: [Flightgear-devel] (no subject)

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 mailto:tors...@t3r.de>> Hi Tomash the navradio code is far from being perfect and and least to attempts

Re: [Flightgear-devel] (no subject)

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 false in your aircraft xml as does the SenecaII. Note: this is st

Re: [Flightgear-devel] Autopilot filters

-pass like low-pass or high-pass. 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 *To:*

Re: [Flightgear-devel] Autopilot filters

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 XM

Re: [Flightgear-devel] reminder: entering feature freeze now

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 spon

Re: [Flightgear-devel] SimGear build fails

Am 27.06.2013 09:58, schrieb James Turner: On 26 Jun 2013, at 23:05, Thomas Geymayer > 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 change over the

[Flightgear-devel] SimGear build fails

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 artef

Re: [Flightgear-devel] reminder: entering feature freeze now

> 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 sett

[Flightgear-devel] reminder: entering feature freeze now

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 http://code.google.com/p/

[Flightgear-devel] Once again, the next release...

Hello everybody, this is just a short reminder, that the development cycle for the next release is about to end in roughly two weeks from now. Please get your new features for the next release commited before June 17th. Even if you already know our release plan (http://wiki.flightgear.org/Relea

Re: [Flightgear-devel] Compasses, magnetic variation, and stuff

> Yes, it's very interesting. My chart for Ireland specifically warns > about the large variation (+5W) which I'm sure catches people out. And > that's before you have to add variation due to the airframe ! which is call deviation ;-) Torsten ---

Re: [Flightgear-devel] Low visibility issues

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

Re: [Flightgear-devel] Release 2.10.0: final tags for 2.10.0

> 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.

Re: [Flightgear-devel] Release 2.10.0: Decision Altitude

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 To

Re: [Flightgear-devel] Release 2.10.0: final tags for 2.10.0

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

[Flightgear-devel] Release 2.10.0: Decision Altitude

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

[Flightgear-devel] Final release checklist

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?

Re: [Flightgear-devel] Release candidates

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 29.

Re: [Flightgear-devel] Updated Short Reference for 2.10.0

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 > w

Re: [Flightgear-devel] Ati viewport bug

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

[Flightgear-devel] Sync with JSBSim

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

Re: [Flightgear-devel] Heads up: release branches are ready,

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 mast

[Flightgear-devel] Heads up: release branch creation startet NOW

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 candidat

Re: [Flightgear-devel] JSBSim Synch with FlightGear

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,

Re: [Flightgear-devel] [Jsbsim-devel] JSBSim Synch with FlightGear

h JSBSim > prior to the release 2.10 > https://gitorious.org/fg/flightgear/merge_requests/40 > I hope it is no already too late... > > Bertrand > > > 2013/1/6 Torsten Dreyer mailto:tors...@t3r.de>> > > Hi JSBSim and FlightGear lists,

Re: [Flightgear-devel] JSBSim Synch with FlightGear

> 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 acti

Re: [Flightgear-devel] JSBSim Synch with FlightGear

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. >

[Flightgear-devel] JSBSim Synch with FlightGear

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

Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013): Version 2.10

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

Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013): Version 2.10

> I'll leave this discussion open until the feature freeze on Dec., 17th > to come to a decision by that date. If nobody heavily objects, I'll commit the version number 2.10 later today. Torsten -- LogMeIn Rescue: Anywh

[Flightgear-devel] Release Progress: Feature Freeze is active

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

[Flightgear-devel] Performance

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 wi

Re: [Flightgear-devel] Real-Time Radio Propagation

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 neede

Re: [Flightgear-devel] Real-Time Radio Propagation

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 b

Re: [Flightgear-devel] Real-Time Radio Propagation

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 or

Re: [Flightgear-devel] Which navradio code is considered standard?

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 i

Re: [Flightgear-devel] JSBSim Piston Engine Idle

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 FG

Re: [Flightgear-devel] Real-Time Radio Propagation, Was: Sqlite location

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

Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)

> 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 item

[Flightgear-devel] Next FlightGear release (Feb. 17 2013)

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 synce

Re: [Flightgear-devel] 3d clouds on multi-display systems (was Re: FSWeekend 2012...)

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 Stuar

Re: [Flightgear-devel] FSWeekend 2012...

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

Re: [Flightgear-devel] fgdata trouble

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.

Re: [Flightgear-devel] license

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 can

Re: [Flightgear-devel] Gear transit times

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 def

Re: [Flightgear-devel] FW: Compute ground elevation dynamically for STG format

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 c

[Flightgear-devel] FlightGear 2.8.0 is out!

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 available

Re: [Flightgear-devel] Release 2.8.0 - closing release/2.8.0 branch

>>> 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 versio

Re: [Flightgear-devel] Release 2.8.0 - closing release/2.8.0 branch

Am 14.08.2012 16:06, schrieb Tim Moore: > On Tue, Aug 14, 2012 at 3:40 PM, Curtis Olson wrote: >> On Tue, Aug 14, 2012 at 3:30 AM, Torsten Dreyer wrote: >>> >>> Hi all, >>> >>> I have just suggested off-list to close the release/2.8.0 branches >>

[Flightgear-devel] Release 2.8.0 - closing release/2.8.0 branch

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

[Flightgear-devel] Changelog for Release 2.8.0

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

Re: [Flightgear-devel] CAVOK METAR interpretation

>> 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

Re: [Flightgear-devel] CAVOK METAR interpretation

> 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

[Flightgear-devel] Release 2.8.0: feature freeze starts now

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 t

Re: [Flightgear-devel] [PATCH] simgear: update .gitignore to include all current build results

Am 09.06.2012 06:30, schrieb Chris Forbes: > simgear build off /next was leaving a bunch of untracked and unignored > files lying around. most of these are new binaries, but some are > intermediate files generated during the build. We recommend to build outside the source tree. Don't use "cmake ."

Re: [Flightgear-devel] The next FlightGear release (summer 2012)

ta sync probably for some months with the change, but I > guess this is the part which can be updated out of core release cycles and > base package anyway. > > Cheers, Yves > > > > Am 02.06.2012 um 21:36 schrieb Torsten Dreyer: > >> Hi, >> >> in just a bit mo

Re: [Flightgear-devel] The next FlightGear release (summer 2012)

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 &g

[Flightgear-devel] The next FlightGear release (summer 2012)

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 reposito

[Flightgear-devel] updates to nav.dat.gz

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 -

Re: [Flightgear-devel] Updated Cub and c172p for Rembrandt

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), >> bri

Re: [Flightgear-devel] More Rembrandt Feedback

> 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 -- Bett

Re: [Flightgear-devel] Flightgear and Simgear multiple format string vulnerabilities

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, because

Re: [Flightgear-devel] auto-coordination

uired! Torsten Am 10.03.2012 15:21, schrieb syd adams: > Sounds good to me.Thanks for dealing with this. > Syd > > On Sat, Mar 10, 2012 at 2:45 AM, Torsten Dreyer wrote: >> This is in fact my preferred solution. >> - it does not break existing aircraft >> - it keeps

Re: [Flightgear-devel] Willfully violating Google Terms of Use under the FlightGear umbrella ?

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=5&t=15711&p=152972&sid=0383829e2324ecb1bc0c0ed67655e826#p152945 > > I checked with the institu

[Flightgear-devel] Sunrises 1.2 commit

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 wor

Re: [Flightgear-devel] auto-coordination

table.Thanks Torsten. > > On Fri, Mar 9, 2012 at 1:32 PM, Torsten Dreyer wrote: >> 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 &

Re: [Flightgear-devel] auto-coordination

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 anythin

Re: [Flightgear-devel] auto-coordination

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

Re: [Flightgear-devel] Two small weather issues

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? ;-) > simgear/

Re: [Flightgear-devel] auto-coordination

Am 09.03.2012 07:51, schrieb syd adams: > On Thu, Mar 8, 2012 at 10:19 PM, Curtis Olson 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 command

Re: [Flightgear-devel] Two small weather issues

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 ver

Re: [Flightgear-devel] Double Input Resolution?

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 g

Re: [Flightgear-devel] Double Input Resolution?

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 wi

[Flightgear-devel] Rembrandt feedback (was: Project Rembrandt - next steps)

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

Re: [Flightgear-devel] Project Rembrandt - next steps

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 fi

Re: [Flightgear-devel] Project Rembrandt - next steps

>> 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

Re: [Flightgear-devel] Project Rembrandt - next steps

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

Re: [Flightgear-devel] Windturbines facing in wrong wind direction

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

Re: [Flightgear-devel] Windturbines facing in wrong wind direction

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 an

Re: [Flightgear-devel] Windturbines facing in wrong wind direction

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 /environment/wind-speed-k

Re: [Flightgear-devel] Windturbines facing in wrong wind direction

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, > possi

Re: [Flightgear-devel] Sanitizing materials.xml

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 materia

Re: [Flightgear-devel] Bug in config file handling

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 y

Re: [Flightgear-devel] Bug in config file handling

Am 21.02.2012 15:32, schrieb Stefan Gofferje: > During my tinkering with Sunrises 1.1, I added the following for the > section: > > > Local Weather Rules > Environment/local-weather-rules.xml > > Doing so replaces the property-rule defined in the global preferences.xml at

Re: [Flightgear-devel] git question

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 fr

[Flightgear-devel] FlightGear 2.6.0 Release(d)

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 this

Re: [Flightgear-devel] (no subject)

Am 18.02.2012 10:55, 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 :-( >>> > >> Of course, it's never too late to be included in the master branch, >> which means that it will

Re: [Flightgear-devel] Aircraft ratings on the download page (was Re: Fair practice & autorisations)

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

[Flightgear-devel] release/2.6.0 development ends today

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

Re: [Flightgear-devel] Final 2.6.0 Release Preparations

> 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 gra

Re: [Flightgear-devel] Local Weather menu structure

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" :-)

[Flightgear-devel] Final 2.6.0 Release Preparations

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 changel

Re: [Flightgear-devel] Shader performance

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 limit

[Flightgear-devel] smooth animations or: what is property-interpolate for?

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, sta

Re: [Flightgear-devel] screen.nas FONT size

Hi Curt, add 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 My first Text 0 0 0 -20 0.0 2.0

Re: [Flightgear-devel] screen.nas FONT size

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 pixe

  1   2   3   4   5   6   7   8   9   >