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

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

[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

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

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] [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 ."

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

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

[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

[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

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

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

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

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

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

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

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

[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

[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

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

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

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

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

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,

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

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

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

[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

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

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

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

[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

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

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

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

[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

[Flightgear-devel] FlightGear 1.9.0 review

Hi I found a first review of the 1.9.0 release. If you are able to read the german language, click here: http://www.chip.de/downloads/FlightGear_15932278.html As of today the page counts a tremendous number of more than 73000 downloads. Is that a success story or what? There are 90% thumbs up

[Flightgear-devel] Supply (voltage) for instruments: True, >1.0, 12.0, !=0 ?

Am Donnerstag, 1. Januar 2009 schrieben Sie: > On 01/01/2009 04:42 AM, you wrote: > > The usage of the electrical/outputs nodes is somewhat messy: > > I agree. > > > dme.cxx interprets it as boolean, anything other than 0 is "on" > > adf.cxx interprets it as "kind of boolean", anything below 1.0 is

Re: [Flightgear-devel] Supply (voltage) for instruments: True, >1.0, 12.0, !=0 ?

> I don't think a normalized voltage makes any sense. It should be real > voltage in volts. Then the particular instruments should check for > acceptable input voltage. I must be missing some point, what's wrong > with this approach? Nothing is wrong with this approach, but the normalized, dimensio

Re: [Flightgear-devel] Supply (voltage) for instruments: True, >1.0, 12.0, !=0 ?

> Not really my area of expertise, but I'd far prefer to use real volts, > and have the aircraft electrical system define globally what it > considers nominal to be to, i.e what John proposed with: > > For designers who prefer real volts: >/systems/electrical/nominal = 12 >/systems/elec

Re: [Flightgear-devel] Dots, degrees and magic '5's

> For the GS, John states that the 'usable' part is only 0.7 degrees > thick. I'm unsure what usable means in that context, but given then > +/- 0.8 DDM range used by the Mk-VIII GPWS, and their dots-to-DMM > factor of 0.0875 for the GS, maximum deviation is 9.142 **dots**. > Clearly that's a muc

Re: [Flightgear-devel] Supply (voltage) for instruments: True, >1.0, 12.0, !=0 ?

> I am moving this to the flightgear-devel list so we have a bigger chance of > getting some valueable comments or suggestions ;-) OK - that turned out very well: many good comments and suggestions! Thanks everybody for spending your time on this topic. I don't want to waste more of it by rewindi

Re: [Flightgear-devel] Dots, degrees and magic '5's

> > /instruments/navradio[n]/heading-deviation-deg: [-10.0 to 10.0 for a > VOR, -2.5 to 2.5 for a LOC] (i.e no 'magic 4' multiple for LOCs) > /instruments/navradio[n]/heading-deviation-norm: [-1.0 .. 1.0] > /instruments/navradio[n]/gs-deviation-deg: [-0.7 to 0.7] > /instrume

Re: [Flightgear-devel] Update to data/Aircraft/Instruments-3d/kx165

> I believe that the correct behaviour is as follows: > > Decrementing 126.00 results in 126.97 > Incrementing 126.97results in 126.00 Are you sure? I believe the curren behaviour is correct but not for sure ;-) I check it out within the next few days and drop a line here (probably not before th

Re: [Flightgear-devel] Openal with OpenSUSE ?????

> In that distrib/installation (OpenSUSE 11.1 64bit) > openal , openal-32bit , openal-devel, freealut, freealut-devel > are installed correctly. > > Is there anything new within FG that i have missed ? Building FlightGear on my suse x86_64-11.1 is no sweat - maybe config.log has a hint what's wro

[Flightgear-devel] Segfault in FGAirport::getIteratorForRunwayIdent()

Hi, with cvs as of today, I receive a segfault shortly after starting fgfs; No command line args, no .fgfsrc, no .fgfs directory, standard preferences.xml fresh autogen.sh and configure Here is a backtrace Program received signal SIGSEGV, Segmentation fault. FGAirport::getIteratorForRunwayIdent

Re: [Flightgear-devel] Segfault in FGAirport::ge tIteratorForRunwayIdent ()

One more trace, with log-level=debug, the last thing I see is: Splash screen progress reading aircraft list Splash screen progress reading airport & navigation data Loading Airport Database ... Data file version = 810 End of file reached [FINISHED LOADING] Loading Navaid Databases localizer:IITL,

Re: [Flightgear-devel] Segfault in FGAirport::ge tIteratorForRunwayIdent ()

> If anyone else is seeing this (or isn't, with a clean, up-to-date > tree), that'd be very helpful information, since I'm not. I did some digging with the following result: The code crashes when calling apt->getRunwayByIdent for airport OAKB and runway 29 for the OAKB 29 CAT II ILS. With some d

Re: [Flightgear-devel] Segfault in FGAirport::ge tIteratorForRunwayIdent ()

> It's not clear to me if this as a clean build (in the code sense) - > you say fresh autogen.sh and configure, but that doesn't necessarily > imply existing object files get rebuilt (or does it?) Oh sorry - forgot to mention that I also executed "make clean" > > If anyone else is seeing this (or

Re: [Flightgear-devel] Segfault in FGAirport::ge tIteratorForRunwayIdent()

> On 9 Jan 2009, at 11:17, James Turner wrote: > > If anyone else is seeing this (or isn't, with a clean, up-to-date > > tree), that'd be very helpful information, since I'm not. > > Never mind, I can reproduce this locally on my (Vmware) ubuntu, so > it's something Linux-y, not a build issue. > >

Re: [Flightgear-devel] Very bad surprise with last FG cvs

> Hello, > > What happen now with the Cockpit view > Getting now the cockpit cutted That's the near clipping pane, you might want to add 0.1 in your model-set.xml Torsten > > In addition to it , i have never seen, clouds so well displayed in > reality, look

Re: [Flightgear-devel] [BUG] invalid argument to asin () in Instrumentation/navradio.cxx

Since dist is calculated by using sqrt() it should never become negative. So the line > else if (dist <= -y) angle = -90.0; // against roundoff. is probably not really needed. That leaves the question: what happens if dist becomes zero? Apparently that means you have hit the gs-antenna and you

Re: [Flightgear-devel] [Jsbsim-devel] X-15 issue identified

> Got it, > > The issue is that JSBSIM gets the external atmospheric model > (/environment/params/control-fdm-atmosphere set to true in flightgear). I > assume that imposes flight gear own atmosphere model to the FDM and THIS > model is stuck after 10 ft > > Setting this value to false actuall

Re: [Flightgear-devel] Garmin 400

> I'm excited! I just got FlightGear connected up to a Garmin 400 which > speaks the same protocol as the 430/530. I haven't looked at sending over > fuel and radio information, but all the positional / velocity stuff is > working. I'm going to do some more testing here before committing the new

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation heading_indicator_fg.cxx, 1.5, 1.6

That reintroduces the recently fixed division by zero bug when spin is zero... Instead of calculating double factor = 0.1 / (spin * spin * spin * spin * spin * spin) and later heading = fgGetLowPass(_last_heading_deg, heading, dt / factor) avoid division by calculating double factor = 10 *

[Flightgear-devel] A special day and a special livery

Hi everybody, this is a very special day, not only for you in the US. You have a new president, congratulations. Celebrating this event, I have created a special livery for my experimental model aircraft "DerKleineUhu": The UHU-one (Obama edition). Have a sneak preview here: http://www.t3r.de/f

Re: [Flightgear-devel] Update to data/Aircraft/Instruments-3d/kx165

> > I believe that the correct behaviour is as follows: > > > > Decrementing 126.00 results in 126.97 > > Incrementing 126.97results in 126.00 > > Are you sure? I believe the curren behaviour is correct but not for sure > ;-) I check it out within the next few days and drop a line here (probably

Re: [Flightgear-devel] Update to data/Aircraft/Instruments-3d/kx165

I have been working with this patch for a while now and I think it is an improvement and should be applied. I added some modifications to the original code: In the animation-xml - added support for the SHIFT-KEY modifier so using the mouse wheel without - SHIFT tunes by 25kHz and using SHIFT tu

Re: [Flightgear-devel] FlightGear interview posted

> I did an interview for a blogger named Diego Rodríguez last summer and it > has just been posted. I may have been the only person to read it so far, > but if anyone is interested, here it is: > > http://aerialphenomena.blogspot.com/2009/02/inside-flightgear.html > > Regards, > > Curt. I just dou

Re: [Flightgear-devel] Update to data/Aircraft/Instruments-3d/kx165

> The attached patch sets the mask and min/max values appropriately > for the kx165-1, and merges in Torsten's changes for shift-scrollwheel. Good catch! It's committed with the tiny modification of setting max frequency for the comm part to 137.00 instead of 140.00. Torsten

Re: [Flightgear-devel] "proper" ground reactions (was "YASim & sliding helicopters bug")

> Where is the "proper" gear model patch, Martin? mail.flightgear.org > is down so the archives prior to 2005 are unreachable. I'm interested > in taking a look. > > I'm also wondering what is stopping you from grabbing a copy of > JSBSim, applying the patch, and providing some data to the "power

[Flightgear-devel] [PATCH] to enhance translate animation

Hi, the rotate animation has two ways to define a axis 1. by using center/x-m and axis/[xyz] 2. by using axis/[xyz]1-m and axis/[xyz]2-m The translate animation only supports method 1. and here comes a patch that enables method 2 for this animations, too. Works fine for me and makes life a litt

Re: [Flightgear-devel] [PATCH] to enhance translate animation

> I'd be happy if someone considers commiting this. >... > > Index: animation.cxx > === > RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/model/animation.cxx,v Hmmm - nobody? --

[Flightgear-devel] METAR++ or: live wind aloft data for FlightGear

Hi, as a proof of concept, I have a little hack that provides live wind aloft data for FlightGear. A draft can be found here: http://wiki.flightgear.org/index.php/Howto:_Fetch_live_aloft_data Comments welcome. Torsten

Re: [Flightgear-devel] Property System Overview?

> Pretend Curt is in a meeting and he's given 30 seconds to explain the > property system to smart people who have never seen this concept before. > I've just burned my first 15 seconds with "U, er, It's like , > you know " Now all these smart people are scowling. Now what!?! I'd

Re: [Flightgear-devel] handling AI objects

> hi > > I would like to know if flightgear source code has any function which can > create/remove/control AI objects ( aircraft, cars etc...) > > thx Certainly it has. You might want to read this: http://wiki.flightgear.org/index.php/AI_Systems Torsten -

Re: [Flightgear-devel] Flightgear-devel Digest, Vol 34, Issue 21

In this case you might want to check out the UFO. It has some very fancy code for placing objects in the scenery by clicking on the ground. The basic nasal function doing the trick is geo.put_model() (look in your data/Nasal directory for the file geo.nas). This just places a model into the scen

Re: [Flightgear-devel] Mouse FoV control patch

> Hi All, > > Like many people, I find I use the mouse in View mode, and x/X to zoom in > on the instruments in the cockpit. > > While making an update to The Manual to document the various mouse modes > and controls, I noticed that mice.xml defines the mouse scrollwheel for > controlling trim in a

Re: [Flightgear-devel] AIrcraft still refering to space-bar for starting

> ./ogel/ogel-set.xml Fixed - thanks for pointing it out. Torsten -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily

Re: [Flightgear-devel] c172p-dual-pilot broken

> In the longer run it would be nice to merge the dual control > functionallity into the kx165 units in Instruments-3d instead of having > separate versions. I'll look into it within the next two or three days. Torsten --

Re: [Flightgear-devel] Seneca II HSI problem

> On Fri, 2009-03-13 at 11:27 +, Alasdair Campbell wrote: > > I have noticed that the seneca's HSI is permanently stuck at 360° > > Can someone please let me know if they experience the same problem? > > In my case this problem has been present for a long time. > > Can anyone help? > > Sorry, I

<    1   2   3   4   5   6   7   8   9   >