Re: [Flightgear-devel] Ridge lift seems broken

>> var setLift = func (lift) { >> setprop("/environment/local-weather-lift",lift); >> } > > Please change it on GIT and I'll change it for my next version - however > I'd suggest to name the property > > /environment/local-weather-lift-fps > > for consistency. Done in master and release/

Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository

> Sound good? Any nominations? I favor the an2, which I like, has lots > of textures and sounds, and which hasn't seen any recent activity. Sounds good! Another one might be Vostok-1. It eats up 166MB and has only three commits. Torsten ---

Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository

> I wouldn't touch the Vostock right now, it might be taken as an afront > by the author (*Shrugs*) Looking at disk size, this list might help making decision. (from du -ms *|sort -n) 47 an2 47 F-8E-Crusader 48 A340-600 50 f16 51 Short-Stirling 58 D510 65 CRJ700-

Re: [Flightgear-devel] Local Weather - backward compatibility

Am 04.08.2011 08:57, schrieb thorsten.i.r...@jyu.fi: >> Please note, the check for >> features.can_disable_environment == 1 is gone now. It doesn't make any >> sense there. > > In a current GIT, none of the checks make any sense, because current GIT > always has all the features. On the other hand,

[Flightgear-devel] Release 2.4.0: on short final

Hi all, after having passed the outer marker (distribution of release candidates for Windows&OSX) on our final approach into runway 2.4.0 of FlightGear international, we getting closer to our scheduled touchdown on Wednesday, 17th. We will hit the decision altitude next weekend when we will ma

Re: [Flightgear-devel] Release 2.4.0: on short final

Am 08.08.2011 23:07, schrieb Torsten Dreyer: > Hi all, > > after having passed the outer marker (distribution of release candidates > for Windows&OSX) on our final approach into runway 2.4.0 of FlightGear > international, we getting closer to our scheduled touchdown on > We

Re: [Flightgear-devel] Release 2.4.0: on short final

> 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

Re: [Flightgear-devel] Release 2.4.0: on short final

orsten Am 12.08.2011 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 p

[Flightgear-devel] [OT] D-EEQA, the FlightGear C172

Hi, just for the fun of it - here are 55 pictures of the Cessna's transportation from the tiny airfield of Wahlstedt (EDHW) to my home. http://www.c172fg.de/ Hope you like it, Torsten -- uberSVN's rich system and user a

Re: [Flightgear-devel] FlightGear v2.4 is Released!

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 > web site here: > > http://www.flightgear.org/announcements/flightgear-v2-4-0-released/ > >

[Flightgear-devel] Release Plan improvements, was: FlightGear v2.4 is Released!

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

[Flightgear-devel] SimGear, FlightGear and FGDATA "master" branches

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

[Flightgear-devel] new feature for :

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 elements by introducing an optional element. Without the element the behavior is unchanged and existing conditions

Re: [Flightgear-devel] ATC and radio signal attenuation

Am 04.09.2011 14:15, schrieb Adrian Musceac: > I have started to implement radio signal attenuation into the ATC subsystem, > with the goal to later move this to it's own location. > I have chosen the Irregular Terrain Model (ITM) developed by Longley-Rice in > the 70's for several reasons: [..] Hi

Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.

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

Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.

", > " /sim/aircraft-operator" > ); > > and copy that to the SenecaII nasal directory, would 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, schr

Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.

> Or just: > > > >/sim/dimensions/radius-m >/sim/dimensions/parkpos-offset-m >/sim/aircraft-class > > > > from where it's read by aircraft.nas already. Excellent! I'm learning something new every day... > But then again: static aircraft

Re: [Flightgear-devel] A collection of issues

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 t

Re: [Flightgear-devel] A collection of issues

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

Re: [Flightgear-devel] A collection of issues

Am 07.10.2011 08:55, schrieb thorsten.i.r...@jyu.fi: >> Hmm - after double-checking, it looks good to me. > >> Checked with running --prop:/environment/terrain/area[0]/enabled=1 > > That seems to be the key, thanks. Works fine if I set the property on > startup in the commandline, doesn't work if I

Re: [Flightgear-devel] New environment properties (Was: A collection of issues)

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

Re: [Flightgear-devel] Cloud shadows

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 -

Re: [Flightgear-devel] GIT

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

Re: [Flightgear-devel] Cmake (soon)

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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

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 > and for the aircraft it's lik

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

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 pre

Re: [Flightgear-devel] Enabling HLA - missing RTI.hh

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

Re: [Flightgear-devel] fgdata: Important note

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 s

[Flightgear-devel] Reminder for the release process for version 2.6.0

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 f

Re: [Flightgear-devel] Marketting of 2.6.0 via FS Break podcast

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 s

Re: [Flightgear-devel] Deadline problem approaching

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

Re: [Flightgear-devel] turbine inlet temperature in the seneca (TIT)

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

Re: [Flightgear-devel] Snow line based on METAR

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

Re: [Flightgear-devel] OT: git question

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 en

Re: [Flightgear-devel] OT: git question

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 mailto:anders-...@gidenstam.org>> wrote: On Tue, 13

Re: [Flightgear-devel] Cessna 172p cockpit improvement

> 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

[Flightgear-devel] 2.6.0 Release progress: Feature Freeze established

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 ne

Re: [Flightgear-devel] Cessna 172p cockpit improvement

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

Re: [Flightgear-devel] Trying to get more performance out of the 3Dclouds!

> 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

Re: [Flightgear-devel] Cessna 172p cockpit improvement

> > I prefer manually syncing and checking that the changes are valid, rather than > blindly over-riding what we've already got. Hi Stuart, this - -aero/alpha-rad - +aero/alpha-rad -1.8000 r

Re: [Flightgear-devel] Cessna 172p cockpit improvement

> Agreed - that's a mistake in my checkin. I will correct it. > > -Stuart OK - one more. velocity including the propulsion induced velocity. velocities/u-aero-fps propulsion/engine/prop-induced-velocity_fps propulsion/engine/prop-induced-velocity_fps Why is prop-indu

Re: [Flightgear-devel] Cessna 172p cockpit improvement

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

Re: [Flightgear-devel] Local Weather 1.4

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 res

Re: [Flightgear-devel] Local Weather 1.4

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

Re: [Flightgear-devel] Change in telnet string get behavior, or string change?

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 ;-) Cheers, Torsten Am 30.12.11 21:03, schrieb G

Re: [Flightgear-devel] Change in telnet string get behavior, or string change?

> 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

Re: [Flightgear-devel] Reminder for the release process for version 2.6.0

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

Re: [Flightgear-devel] Flightgear-devel Digest, Vol 69, Issue 9

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

Re: [Flightgear-devel] Creation of the release-branches TOMORROW!

22:18, schrieb 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? &

Re: [Flightgear-devel] Creation of the release-branches NOW

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 &

Re: [Flightgear-devel] Release-branches READY

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

[Flightgear-devel] weather-utility.nas

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: http://gitorious.org/fg/fgdata/commit/9b2e72e12d9a07b58

Re: [Flightgear-devel] weather-utility.nas

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 movi

Re: [Flightgear-devel] weather-utility.nas

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

Re: [Flightgear-devel] Local Weather menu structure

> 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

Re: [Flightgear-devel] weather-utility.nas

> 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

[Flightgear-devel] [OT] Riding the cannonball

This reminds me a bit on Münchhausen's ride on the cannonball: http://de-de.facebook.com/photo.php?fbid=281725951859631&set=pu.281671675198392&type=1&theater But it certainly looks like great fun! Torsten -- Try before y

Re: [Flightgear-devel] weather-utility.nas

> Played around with it a bit. I got reasonable "movement" sensation with > wind-filter-time set at ~1000. > > The flutter effect might need the wind in realtime though, as flags > usualy react imediately to wind direction changes. Huh - that's a huge value. With a filter-time that high, it will ta

Re: [Flightgear-devel] Local Weather menu structure

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

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

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

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

Re: [Flightgear-devel] Separate Instruments Display

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 &

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

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

<    1   2   3   4   5   6   7   8   9   >