Re: [Flightgear-devel] Default Aircraft Candiates
On Sun, 2011-02-20 at 12:46 -0500, Peter Brown wrote: > > This is very true. I've not explored the parameters of the 777 in FG, > but if you fly the MD-81 with no passengers, 1200 lbs of fuel and crew > weight, it is extremely different than flying with standard fuel load > and passengers. Enough so that you can land, and take off, from the > Nimitz. This is not as far-fetched as one may think. In fact this has been proposed for the F28; It was named the F-28 COD (Carrier On-board Delivery) http://eu.airliners.net/aviation-forums/military/read.main/43434/ Erik -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
To be honest I think most companies would see their logo ending up on a virtual aircraft as a way to get free advertising; That is; as long as it's a genuine representation of their business. In this case I would therefore argue; Keep it real and stay out of trouble. I could easily see Red-Bull complain about their logo on a assault helicopter and as a result want their logo removed from any aircraft in the database. Erik -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
On Sat, 26 Feb 2011 16:08:32 -0600 Curtis Olson wrote: > On Sat, Feb 26, 2011 at 3:57 PM, Erik Hofman wrote: > > > > > To be honest I think most companies would see their logo ending up > > on a virtual aircraft as a way to get free advertising; > > That is; as long as it's a genuine representation of their business. > > > > In this case I would therefore argue; > > Keep it real and stay out of trouble. I could easily see Red-Bull > > complain about their logo on a > > assault helicopter and as a result want their logo removed from any > > aircraft in the database. > > > > Well I hope Red Bull doesn't see the following link. But hopefully > they'll be so busy suing the jerks that painted their logo on a Cobra > that they won't worry about us: > > http://1.bp.blogspot.com/_KYZKqfdOPt0/THfmWhBVvpI/ALQ/877pUiP9dtk/s1600/cobra+-+flying+bulls.jpg Interesting, I didn't know that an frankly I'm a bit surprised .. was that authorized by Red Bull? If so then I think FlightGear will be safe too. Erik -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos andlicensing
On Sat, 26 Feb 2011 14:23:41 -0800 Jack Mermod wrote: > *facepalm* > > Are you telling me that you guys didn't know that Red Bull owns that > aircraft? > > That's the whole reason I made the livery! To accurately recreate > the newest addition to the Flying Bulls team, the AH-1! Well, I didn't. No idea about the rest. Erik -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
On Sat, 2011-02-26 at 18:37 -0600, Jon S. Berndt wrote: > To be safest we probably ought to rename the Fokker aircraft models as F100 > and F50. I hardly believe that's necessary. I've never heard any complaint about using the Fokker name in any flight simulator. In fact the Fokker project for MSFS does have some support from the Fokker company I believe. Also the situation for JSBSim is slightly different since it only concentrates on the Flight Dynamics part of the simulator and configuration files therefore could be misinterpreted as being accurate. If, after simulated tests, some oddity shows up and someone decides to contact the manufacturer of the particular aircraft then that pushes JSBSim right in front of the radar. So stating that the FDM is in no way endorsed or backed up by the manufacturer actually makes sense. Erik -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
On Sun, 2011-02-27 at 01:57 -0500, Chris O'Neill wrote: > I'm no lawyer, and I'm certainly not up on the law around the world, but > there's a concept in North American common law that one must take > "reasonable and prudent" steps to avoid liability. With this concept in > mind, I respectfully ask whether it is "reasonable and prudent" to > explicitly take the position that we'll "look the other way" when a > possible copyright infringements are occurring? Likewise, is the "if we > don't ask permission they can't say no" position reasonable and prudent? To be honest I don't see any legal difference between creating an accurate livery for a virtual aircraft or publishing a photograph of the real aircraft. Erik -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Livery proposals (was: Logos and licensing)
On Sun, 2011-02-27 at 22:49 +0100, Gijs de Rooy wrote: > Hey Erik! > > > Erik wrote: > > > > It might also be a good time to make installing new liveries a lot > > easier. > > Please let me know whenever something is undertaken on this part. I'd > like to make sur we'll end up with > something in cooperation with http://liveries.flightgear.org which I > maintain currently. Or atleast something > so all those liveries don't get lost. Or a simple way to convert to the new standard :) But agreed, no need to waist previous efforts. Erik -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
On Tue, 2011-03-01 at 12:33 +0100, Oliver Fels wrote: > Jörg Emmerich wrote: > What I can imagine as a solution: FlightGear does not include the liveries in > the distribution but provides further web space for separately downloading > those. I'm starting to believe that a separate repository for clearly labeled GPL models and other freeware or shareware models would be a good idea. GPL'ed models can be put on the same CD/DVD ad the main program but non-GPL models can only be downloaded form the site. Erik -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] list of aircraft that don't load in fgdata
On Thu, 2011-03-03 at 13:51 -0500, Peter Brown wrote: > http://www.mediafire.com/file/zo967hk164bjkzq/OV10%2020110303.zip The files are set to private so I'm unable to retrieve them. Erik -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] list of aircraft that don't load in fgdata
On Fri, 2011-03-04 at 08:51 +0100, Erik Hofman wrote: > On Thu, 2011-03-03 at 13:51 -0500, Peter Brown wrote: > > http://www.mediafire.com/file/zo967hk164bjkzq/OV10%2020110303.zip > > The files are set to private so I'm unable to retrieve them. Odd, the link from the forum does work, anyhow I'm downloading now. Erik -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] list of aircraft that don't load in fgdata
On Fri, 2011-03-04 at 09:23 +0100, Erik Hofman wrote: > On Fri, 2011-03-04 at 08:51 +0100, Erik Hofman wrote: > > On Thu, 2011-03-03 at 13:51 -0500, Peter Brown wrote: > > > http://www.mediafire.com/file/zo967hk164bjkzq/OV10%2020110303.zip > > > > The files are set to private so I'm unable to retrieve them. > > Odd, the link from the forum does work, anyhow I'm downloading now. That version has been pushed to GIT. Let me know if it's up-to-date or if this was a (slightly) older version. Erik -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C or C++?
On Sun, 2011-03-20 at 11:41 +0100, Roberto Inzerillo wrote: > Sorry for being so naive but ... I'm starting now learning C first time > in my life (not even learned C++ ever in the past) and I'm wondering ... > is FGFS written in C or C++? It's more than 99% C++. some very small pieces are C only. Erik -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders
On Mon, 2011-03-21 at 08:50 +0100, HB-GRAL wrote: > Hi all > > Can someone point me to the history of latest changes to the default > shaders? I am running a ATI 5750 now with 1 GB VRAM and get <= 20 fps at > default KSFO, like the last three years with much older ATI. What > happened, I can’t believe. > > Coming back after some months and looking to the development in the > shaders I am a bit disappointed, I spent a lot of work last year to get > the shaders working for ATI/OSX. The quality level takes no effect to > the framerate, 3d clouds are superb and takes no effect, there must be > something wrong again with default shaders. What changes have been > introduced here ? And can someone point me a git header where > fundamental changes were (re-)made, so I dont have to go thru the whole > file history ? The (new) urban shader brings my system to it's knees and the fallback option to the old urban shader has no effect (I get plain white areas instead of an urban shader). I would start to look there if I where you. Erik -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Mon, 2011-03-21 at 13:15 +0200, thorsten.i.r...@jyu.fi wrote: > ... and the winner is: The rgb format. To be honest I was expecting this but didn't have proof for it. Remember that the RGB format was developed by Silicon Graphics to be used for OpenGL and it probably resembled at least the internal format used by SGI back then. Erik -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Mon, 2011-03-21 at 17:50 -0600, syd adams wrote: > Interesting.I just did my own quick test ... converted 1 out of 3 > livery (png) files to a dds with Gimp plugin .Had to flip the image > vertically before converting. I changed liveries with the dialog , and > the 2 png files took several seconds to change , the dds changed > instantly.I saw no difference in quality , but the load time was > impressive.The original png file is 158.6 KB , the dds is 16.8 MB.This > should swell fgdata significantly , unless Tim does (hopefully) does > the /Aircraft split... Maybe a better idea would be to use .dds as a local cached version of texture files but that requires instant conversion upon loading, and dds writing code. Erik -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Best pratice for debugging multi threaded programs?
On Mon, 2011-03-21 at 15:04 +0100, Holger Wirtz wrote:
> Hi all,
>
> sorry - a little bit off-topic (in fact not so much as you might think,
> it's for a third-party software for FG):
>
> Has anyone some hints/websites/programs for debugging C -based multi
> threaded programs (exactly: glib based C code)? Currently I am
> developing with vi and a little bit gdb (command line) and very much
> debug output. But this setup seems to be very frustrating while
> searching for dead-locks and race-conditions :-(
I have my own locking functions that call the pthread ones and added a
small piece of code to check for the mutex value:
pthread_mutex_t mutex;
int mtx = mutex.__data.__count;
r = pthread_mutex_lock(&mutex);
if (mtx != 1) {
printf("Mutex was already locked\n");
}
You could add all kinds of fancy stuff using __FILE__, __FUNCTION__ and
__LINE__ to detect from where the code has been called.
Note: This only works for __GNUC__
Erik
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Tue, 2011-03-22 at 10:33 +0200, thorsten.i.r...@jyu.fi wrote: > these numbers hardly change - I go to 11 fps and my loading time is > unchanged. Somewhat surprisingly, all the matrix operations inside the > shader are apparently a non-issue here. From past experience I know that a > range animation within the xml wrapper is a performance killer though... XML files are a dog to decode into something useful, every XML node has to be processed recursively. It's nice for one time configuration files but I'm starting to wonder if they're that useful for anything more than that. Erik -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Best pratice for debugging multi threaded programs?
On Tue, 2011-03-22 at 11:20 +0100, Holger Wirtz wrote: > I tried the same thing with the glib-pthreads wrappers, but > pthread_mutex_lock blocks until the mutex is unlocked. Perhaps this > should work with pthread_mutex_trylock()? It depends on the mode but you could also test prior to locking if it is already 1 but then you're a but late in the game. > > You could add all kinds of fancy stuff using __FILE__, __FUNCTION__ and > > __LINE__ to detect from where the code has been called. > > Note: This only works for __GNUC__ > > Ok, this seems to be a good way to get more information where the dead > locks are located. I will try this. > > Thanks a lot! You're welcome. Erik -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Instant replay and JSBSim aircraft
On Thu, 2011-03-24 at 00:08 +0100, ThorstenB wrote: > It fixes all the issues I have seen and replay works fine now - so I > pushed it to git. But are the JSBSim.* files officially maintained in > the JSBSim repo (so the patch also needs to be proposed over there) - or > are these files owned by FG now? Yes the FlightGear-JSBSim support code (JSBSim.[ch]xx is maintained in FlightGear now and copied back to the example directory of JSBSim upon synchronization. Erik -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] jbsim nose wheel steering control, 737 models
On Mon, 2011-03-28 at 13:53 +0700, Harry Campigli wrote: > > I have searched high and low in aircraft xml,s and the property tree > for the linkage definition between the rudder pedals and the steering > in JBsim with a view to interfacing a ground nose wheel steering > system. > > But I cant find it any where except in Yasim models? I just use either surface-positions/rudder-pos-norm or gear/gear[0]/steering-norm to animate the nose gear steering since they are interconnected for most cases anyway. For a more fancy steering behavior (for example less steering at higher speeds) you can add a steering channel to toe configuration files like this: gear/unit[1]/WOW eq 1 gear/unit[2]/WOW eq 1 gear/gear-cmd-norm 0 0 1 5 gear/gear-pos-norm fcs/steer-cmd-norm velocities/vg-fps 10.080.0 50.015.0 150.0 2.0 fcs/steer-pos-deg Erik -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] The Canterbury Project: Linux Distros merge
On Fri, 2011-04-01 at 07:43 +0100, Torsten Dreyer wrote: > For those who use Linux, this might be the most interesting news today: > > http://www.debian.org/ > http://www.archlinux.org/ > http://www.opensuse.org/ > http://www.gentoo.org/ > http://grml.org/ > > All unified in a joint project. Even if the date wasn't suspicious I wouldn't believe it until proven.. Erik -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic Protocol Input - Float weirdness
On Sun, 2011-04-03 at 01:52 +0200, Roberto Inzerillo wrote: > Well, readme.protocol does not mention a double format, float only; should I > think double is anyway, just undocumented? I should really study more C++ and > read the code by myself, damn That's an omission in the documentation, you could define "double" instead of "float" without a problem (in the latest code anyway). There have been some fixes in that area, which version are you using? Erik -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic Protocol Input - Float weirdness
On Sun, 2011-04-03 at 01:52 +0200, Roberto Inzerillo wrote: > Well, readme.protocol does not mention a double format, float only; should I > think double is anyway, just undocumented? I should really study more C++ and > read the code by myself, damn Note, you could also define "fixed" which is a fixed point integer representation of a float. (It gets converted automatically) back and forth to a floating point value. Erik -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic Protocol Input - Float weirdness
On Sun, 2011-04-03 at 12:00 +0200, Roberto Inzerillo wrote: > >> Well, readme.protocol does not mention a double format, float only; > >> should I think double is anyway, just undocumented? I should really study > >> more > >> C++ and read the code by myself, damn > > > > Note, you could also define "fixed" which is a fixed point integer > > representation of a float. (It gets converted automatically) back and > > forth to a floating point value. > > Tell me more Erik, what's this fixed type syntax, how could I use it? I > imagine there should be at least a way to define how many decimal digits to > use. Looking at the code: It's a 32-bit integer with 16.16 format meaning (float_val*65535) when sending and (integer_val/65535.0) when receiving it. Erik -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic Protocol Input - Float weirdness
On Sun, 2011-04-03 at 12:01 +0200, Roberto Inzerillo wrote: > > One solution others have used is to express the frequency in kHz instead of > > MHz so use 131925 instead of 131.925 and some nasal magic to copy your kHz > > value to the MHz value. > > > > Ron > > "Others"? Who? Where in the code should I look for it? What should I search > for? The generic protocol code is located in FlightGear/src/Networking/generic.cxx if that's what you're asking. Erik -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 答复: SimGear Compiler Question in VS 2008 Express
On Mon, 2011-04-04 at 09:34 +0800, Chengde Jin wrote: > So I don't know where is the simgear_config.h file? > Maybe that is generation by compiler. > Does any relation with the VS 2008 config? simgear_config.h is generated by autotools (autogen.sh, configure, etc) and is not used for MSVC as far as I know. You should be able to use cmake in the git evrsion of SimGear or use one of the MSVC project files located in the projects directory of SimGear. Erik -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is FlightGear GPL2 and later or GPL2 only?
On Mon, 2011-04-04 at 12:43 +0200, HB-GRAL wrote: > Hi all > > While reading all the licence or license files distributed with fgdata I > have to ask a small question here, and I apologize in advance to open a > new licence thread, I am tired of this kind of threads myself: Normally the licenses are GPL2 or later, the only project I know of that has a different view is the linux kernel. > - Is FlightGear fgdata distributed under "GPL2 and later" or "GPL2 only" ? > > I found following aircrafts distributed under other licences: > > - Mig15 (not compatible to GPL2 at all) > - Fokker100 (GPL3, could not be used with GPL2 only) The Fokker 100 was never released under the GPL3 by me so it's still GPL2. If there's a license stating otherwise it's wrong. -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is FlightGear GPL2 and later or GPL2 only?
On Mon, 4 Apr 2011 17:53:16 +0200 Arnt Karlsen wrote: > > > - Mig15 (not compatible to GPL2 at all) > > > - Fokker100 (GPL3, could not be used with GPL2 only) > > The Fokker 100 was never released under the GPL3 by me so it's still > > GPL2. If there's a license stating otherwise it's wrong. > > ..you meant GPLv2-and-later, not GPLv2-only? GPL2 or later, which doesn't mean the license of the version in the base package can be changed to GPL3 without my permission. Erik -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is FlightGear GPL2 and later or GPL2 only?
On Tue, 2011-04-05 at 01:59 +0200, kreuzritter2000 wrote: > Am Montag, den 04.04.2011, 19:01 +0200 schrieb Erik Hofman: > ha mAa> GPL2 or later, which doesn't mean the license of the version > in the > > base package can be changed to GPL3 without my permission. > > > > Erik > > No, this is exactly allowed. > That's the reason why the two words "or later" were added, when the > GPLv2 was created. No it's not. This is my model an placing my distribution under GPL3 restricts it's license. Anyone is free to fork the Fokker-100 and place it under the terms of GPL3 but the one in the base package is GPL2 (or later) period. Erik -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is FlightGear GPL2 and later or GPL2 only?
On Tue, 2011-04-05 at 10:13 +0200, Arnt Karlsen wrote: > ..I'm guessing you meant to say your fokker100 is going to stay > under the same license as the rest of the base package, now it's > GPLv2-and-later, later it may be GPLv3, GPLv3.1, GPLv4 etc as it > is developed and forked etc to fit new FG things. :o) Hmm, fair enough. Erik -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is FlightGear GPL2 and later or GPL2 only?
On Tue, 2011-04-05 at 12:31 +0200, kreuzritter2000 wrote: > No, the "or" in the passus "GPLv2 or later" is a right to choose. > Someone who gets the code can give it away under the terms of the GPLv2, > but he does not need to do this, when there is a GPLv3 or later license > available. > He can give it away under the terms of GPLv3. Sigh, of course not. The version in the base package is my work so I decide the license of that copy. Erik -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is FlightGear GPL2 and later or GPL2 only?
On Tue, 2011-04-05 at 13:34 +0200, Arnt Karlsen wrote: > ..and we just agreed that my guess on your GPLv2-and-later > license is in your own words "Hmm, fair enough.", which > hopefully is what you meant to do, when you put your work > into FG-base. Look if the license states that one can apply a later license doesn't mean one can alter the original license (text). You for one should know that. Erik -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is FlightGear GPL2 and later or GPL2 only?
On Tue, 2011-04-05 at 14:35 +0200, kreuzritter2000 wrote: > No the base package belongs to the FG community and you commited your > work under their "GPLv2 or later" conditions. > > If the FG community decides to switch to GPLv3 one day, the community > can do this without asking you for permission. Incorrect, the copyright still belongs to me. GPL2 just makes it easier. Erik -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] link error on jpgRenderFrame in next pulled this night.
On Mon, 2011-04-11 at 05:39 +0200, Pascal J. Bourguignon wrote: > I just checked out the next branches in simgear and flightgear and > pulled them, and when compiling with: I think you either need to configure simgear using --with-jpeg-factory or need to doe a 'make uninstall' for simgear before running configure at the flightgear side. Erik -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simple atmospheric scattering shader for skydome
On Wed, 2011-04-13 at 19:37 +0200, Durk Talsma wrote: > Admittedly, I only looked at the corresponding forum topic very briefly, but > the screenshots certainly looked promising. I'd be happy to commit the > corresponding simgear and flightgear patches. > > I did see some comments from Fred in the forum thread and I can't tell for > sure whether these have been addressed or not. Therefore, I'd like to give > others a few days to comment. If I don't hear any objections by the weekend > (and if I don't see any negative side effects myself). I'm might go ahead and > commit these patches by Saturday. So, just drop a note here if there are > problems I should be aware of. It's not production ready yet, and it even removes some of the features form the old code. I don't seem to see any difference with different humidity levels for example. Erik -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simple atmospheric scattering shader for skydome
On Thu, 2011-04-14 at 18:15 +0200, Durk Talsma wrote: > > Okay, thanks for the comments. I'll be holding back on committing. Is > there any perspective that this patch can be brought to production > quality? I'm not sure, it needs time to look after some things. For one it should be made possible for the shader to adjust the fog color located under /rendering/fog but at this time values written to it will be overwritten by the current code. Erik -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simple atmospheric scattering shader for skydome
On Fri, 2011-04-15 at 00:16 +0200, Christian Schmitt wrote: > I can only agee with Vivian here: lets get this change into GIT, so that it > doesn't get lost as so many others in the past. The shader is not perfect > yet, but that should not hurt, as it is disabled as a default. Those who > want to test and improve it are free to do so. > Let me add that it's good to have people who work on things like shaders (we > need every single one of them). I'm not opposed to adding the shaders but I want a good look at the code to make sure that current functionality is not lost with the patch before it gets committed. Erik -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simple atmospheric scattering shader for skydome
On Fri, 2011-04-15 at 11:22 +0200, Durk Talsma wrote: > Like, Christian and Vivian stated earlier, I would also hate to see a patch > getting lost, especially when it contains promise. This is why I originally > suggested committing it. > > I would suggest that (even though it may not be production-ready yet), we > commit the patch on the condition that; 1) the shader in question is disabled > by default, and 2) in its disabled state doesn't have an adverse impact . > > Thoughts / Ideas? Let me take a look at it this weekend and I'll commit it then. Erik -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simple atmospheric scattering shader for skydome
On Fri, 2011-04-15 at 11:27 +0200, Erik Hofman wrote: > On Fri, 2011-04-15 at 11:22 +0200, Durk Talsma wrote: > > Like, Christian and Vivian stated earlier, I would also hate to see a patch > > getting lost, especially when it contains promise. This is why I > > originally suggested committing it. > > > > I would suggest that (even though it may not be production-ready yet), we > > commit the patch on the condition that; 1) the shader in question is > > disabled by default, and 2) in its disabled state doesn't have an adverse > > impact . > > > > Thoughts / Ideas? > > Let me take a look at it this weekend and I'll commit it then. Ok the problem seems to be that the local weather tiles need about a minute to settle down. The code seems fine after all. Erik -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 12
On Wed, 2011-05-25 at 15:51 -0700, Hal V. Engel wrote: > * 5: FDM models out of normal flight envelope characterisics IE. > stalls, spins and compressibility/transonic effects (if the > aircraft can reach transonic speeds). Darn, I did go to great lengths to develop a flight computer to prevent these conditions for the F-16.. :-) Erik -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 12
On Thu, 2011-05-26 at 10:52 +0200, Arnt Karlsen wrote: > On Thu, 26 May 2011 08:57:18 +0200, Erik wrote in message > <1306393038.2534.1.camel@Raptor>: > > > On Wed, 2011-05-25 at 15:51 -0700, Hal V. Engel wrote: > > > * 5: FDM models out of normal flight envelope characterisics > > > IE. stalls, spins and compressibility/transonic effects (if the > > > aircraft can reach transonic speeds). > > > > Darn, I did go to great lengths to develop a flight computer > > ..can it crash|bluescreen|"departure" like the real one did > in a few cases? Neh that was the F-22 :-) > to prevent these conditions for the F-16.. :-) > > ..a _very_ small number of men survived because they were able > to get at least one of their hands off the stick or throttle > and onto that black and yellow ejection handle. _Hard_ to do > in a F-16 going low and fast into a tumble. For those who didn't know, the F-16 has angle of attack and G limiters to always be able to control the aircraft. This sometimes works against the pilot but in most cases it saves some lives. Erik -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object distance fading color
On Wed, 2011-06-01 at 14:50 +0300, thorsten.i.r...@jyu.fi wrote: > I've recently done a visual comparison between hires Flightgear scenery > and reality - for those interested, see here: > > http://www.flightgear.org/forums/viewtopic.php?f=5&t=12259 > > One of the striking points is that in reality even in partially clouded > skies distant objects do not start to fade into white (as the Flightgear > terrain shader assumes) but into darker colors, sometimes providing a > striking contrast with the horizon sky color before they fade into the > horizon color at even larger distance. > > I've played a bit with /rendering/scene/saturation to see if there was a > way to recover that, but it didn't seem to do the right thing. > > I believe the relevant parameter is the amount of light reaching the > surface at a given altitude. Naturally, the terrain shader can't know that > up front, but the weather system has all the the information needed. > > If anyone is interested in attacking that problem from the shader side by > exposing a property which can dial the 'darkness' of distant objects when > they start to lose their color, I'd be happy to do my part from the > weather side and cook up a model which sets the parameter value dependent > on conditions. Part of the problem is that FlightGear almost always renders ideal situations for the skydome. If you look at this picture you see there are situations where white fog is natural: http://upload.wikimedia.org/wikipedia/commons/2/2a/St.Gilgen_Panorama_2007-02-22.jpg But you obviously won't get that with the sun hidden behind a cloudy sky. Erik -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object distance fading color
On Thu, 2011-06-02 at 12:53 +0300, thorsten.i.r...@jyu.fi wrote: > Yes, that was my analysis as well. My point is - the skydome or terrain > shader code can't know a priori. But all our weather systems have the > relevant information readily available - all we need to do is expose a > property which tells the distance fading code how much sunlight is > available at a given altitude (below a layer, mountains should fade to > dark, above to white for instance). I'll see what I can come up with this weekend. On another note: I seem to remember you had another request for the weather system but I was too busy to remember it. Do you remember what that was? Erik -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object distance fading color
On Fri, 2011-06-03 at 10:36 +0300, thorsten.i.r...@jyu.fi wrote: > > I'll see what I can come up with this weekend. > > Thanks, much appreciated! I've pushed a code change to be able to control the amount of light scattering (or absorption) of the fog by adjusting the /rendering/scene/scattering property. A value of 1.0 is full scattering and a value of 0.0 is full absorption (unrealistic). The default is set to 0.8 now. This did however revealed a sun position and for brightness position mismatch that I've confirmed was already in the code before this change. I can't believe no one noticed the massive offset at dusk (for KSFO) before. > > On another note: I seem to remember you had another request for the > > weather system but I was too busy to remember it. Do you remember what > > that was? > > I was toying with the idea to model diffuse high-altitude haze by coloring > the skydome as a function of altitude, i.e. paint the zenith a bit more > hazy without touching the horizon and remove that effect again as you get > above the haze layer - I believe that might create a better impression of > such diffuse layers than placing texture sheets into the scene. Ah yes, that was it, need to take another look at that then. Erik -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object distance fading color
On Sat, 2011-06-04 at 15:03 +0200, Torsten Dreyer wrote:
> prop->tie("/environment/relative-humidity",SGRawValuePointer(&_humidity));
>
> is probably not a good idea since the FGEnvironment ties to this property,
> too (and it's
> the system that "owns" aka calculates this property.
>
> You should use getNode() and getDoubleValue() instead.
You're probably right, I didn't think of that. This part is reverted
now. Thanks.
Erik
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object distance fading color
On Fri, 2011-06-03 at 10:36 +0300, thorsten.i.renk jyu.fi wrote: > I was toying with the idea to model diffuse high-altitude haze by coloring > the skydome as a function of altitude, i.e. paint the zenith a bit more > hazy without touching the horizon and remove that effect again as you get > above the haze layer - I believe that might create a better impression of > such diffuse layers than placing texture sheets into the scene. Code for this has now been pushed to GIT. There is now a new property /rendering/scene/overcast ranging from 0.0 (normal behavior) to 1.0 (complete overcast). Erik -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object distance fading color
On Sun, 2011-06-05 at 10:26 +0200, Erik Hofman wrote: > On Fri, 2011-06-03 at 10:36 +0300, thorsten.i.renk jyu.fi wrote: > > I was toying with the idea to model diffuse high-altitude haze by coloring > > the skydome as a function of altitude, i.e. paint the zenith a bit more > > hazy without touching the horizon and remove that effect again as you get > > above the haze layer - I believe that might create a better impression of > > such diffuse layers than placing texture sheets into the scene. > > Code for this has now been pushed to GIT. > > There is now a new property /rendering/scene/overcast ranging from 0.0 > (normal behavior) to 1.0 (complete overcast). Come to think of it, this might not be exactly what you're looking for but it could be useful to render overcast without an extreme amount of cloud vertices. Need to dig deeper to only affect the zenith of the skydome since that's handled elsewhere. Erik -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Please insert disk into drive F:
On Sun, 2011-06-05 at 13:07 +0400, Slavutinsky Victor wrote: > > -Fred > > Little bit other topic. > > Hi Frederic, I have two questions for You. > > 1) Can Your terrain engine be added in FG? > 2) Can it be fast enough for orbital flight with visibility ~500km and > speed ~3km/h, ~8km/sec? There might be some more questions involved: 3) Is it an accurate representation of the world or a procedural terrain engine. 4) Are you willing to /and/ able to release it under the terms of the GPL. Erik -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object distance fading color
On Sun, 2011-06-05 at 14:34 +0200, ThorstenB wrote: > On 05.06.2011 10:26, Erik Hofman wrote: > > There is now a new property /rendering/scene/overcast ranging from 0.0 > > (normal behavior) to 1.0 (complete overcast). > > Just wondering: we have /sim/rendering, which contains a long list of > properties - including properties for clouds and precipitation. And we > have /rendering which contains the scene/dome properties only. Is there > a specific reasons these are separate? Not that I know of, but I was always under the impression that /sim/rendering was honored once at startup only. Erik -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
On Thu, 2011-06-16 at 07:35 +, Martin Spott wrote: > ThorstenB wrote: > > But this and other posts today show [...] > > This is by far the best characterization of The FlightGear Projects > age-old disease I've ever read, As I see it there are two sides to the story, users who criticize too quickly but also developers who don't seem to handle criticism particularly well (not that I'm accusing Thorsten here). Add to that that non native English speakers might sound a bit short cut to native English speakers and that non native English speakers might find comments from other non native speakers insulting because of these misunderstandings while there's actually no intention to do so and there's a problem. Personally I like the idea of being able to fetch new scenery from within FlightGear itself. Working a bit more towards what users expect and appreciate isn't a bad thing, it could even attract new developers who might just want to work on the areas you think FlightGear is lacking (scenery, selecting a new aircraft at runtime). That's how it has always worked so far. The first 3d models weren't particularly attractive but showed that it works and that attracted new developers. Because of that the 3d models created these days are just about the best you can get. Erik -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Could We Sync JSBSim for 2.3.0, Please?
On Thu, 2011-06-16 at 22:23 -0500, Jon S. Berndt wrote: > I am very close to committing the new atmosphere code (and the new FGWinds) > to JSBSim cvs. However, it would be prudent to first get a glitch or two > fixed and then grab that code and put that in FlightGear first, just in case > the newer atmosphere and winds code causes problems. Alright, the current state of JSBSim has been pushed to FlightGear GIT. Erik -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
On Fri, 2011-06-17 at 10:55 +0300, thorsten.i.r...@jyu.fi wrote: > At this point, it made a lot of sense to code in Nasal, if only for the > simple reason that I couldn't know if it would ever included into the base > package or not. As an addition it also helped to develop good insight in efficient Nasal programming which might prove to be very useful in the future. Erik -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Fri, 2011-06-24 at 10:48 +, TDO_Brandano - wrote: > Ok, before I get flamed to a crisp, let me explain what is my > reasoning behind this. Right now the fgdata repository is about 9 GB. > This makes it really, really difficult to obtain an initial checkout > of the fgdata folder, expecially for people that do not have a very > good connection. at the same time it is not possible, to my knowledge, > to only grab part of the repository. And most people don't really need > he entire repository anyway. GIT is fantastic to handle code with many > contributors, but I think it is really overkill for airplanes, where > usually the number of people contributing to a single plane is fairly > small and is unlikely that two people should work on the same file at > the same time. Also, using SVN for planes the same way that is being > used for scenery would allow individual planes to be pulled by a > frontend, much like scenery is. Or even to be pulled by FGFS itself, > though that's probably science fiction at this moment in time. So, is > this something that could be implemented in the future? Am I barking > up the wrong tree? I can foresee some issues, like, where should the > repository be hosted, any other thing I have overlooked? It has been proposed before and I believe it's the way to go. It's just a matter of someone stepping up for the task. Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Could We Sync JSBSim for 2.3.0, Please?
On Thu, 2011-06-30 at 10:11 -0600, Ron Jensen wrote: > There have been a few bug fixes to JSBSim since this sync, notably: > > src/FDM/JSBSim/models/flight_control/FGActuator.cpp > src/FDM/JSBSim/models/flight_control/FGFCSComponent.cpp > src/FDM/JSBSim/models/flight_control/FGFCSComponent.h > src/FDM/JSBSim/models/flight_control/FGSwitch.cpp > src/FDM/JSBSim/models/propulsion/FGTank.cpp > > We don't want a whole-sale sync but if these six files were updated, that > would be great. Since the addition of the new environment code to JSBSim I've been hesitating to sync again but only copying these files doesn't seem to break anything so it's pushed to git. FGFCSComponent.h and FGSwitch.cpp don't seem to have any updates. Erik -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Turbulence in YASim vs. JSBSim
On Mon, 2011-07-11 at 14:45 +0300, thorsten.i.r...@jyu.fi wrote: > I've first suspected that something is fishy with the DG-101G, but since > I've flown all sorts of aircraft through the thermals (as a side note, > it's really interesting that the F-16 instrumentation allows nicely to > trace the thermal rise profile - I hadn't expected that). Of course, an > F-16 isn't thrown so wildly around as the DG-101G for the same magnitude > of turbulence , but then it has 100 times the mass .. and the F-16's flight computer compensates for non commanded aircraft movements. Note that the JSBSim environment model is in the middle of a major overhaul so I wouldn't make too much of it at this point. It would be more interesting to see how it compares after the rewrite. Erik -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
On Wed, 2011-07-13 at 15:24 +0200, grth_team wrote: > FG 2.4 consistency. > > Hello, > > You don't know us since we are newbee, (3 months working seriously > with FG). > We are a team ( 4 guys and a lady ). > > We have had several talks with several devel team persons about a > Catalina model update. > > That update has been rejected arguing that everything is frozen until > FG 2.4 will be freed, considered consistent, without any bug. It's not so much rejected, but declined to be included in GIT. The current release process is quite new to all of us so there might come up some unforeseen problems. Clearly this is one of them. It's unfortunate since you've put so much work in it, but then remember; so have all of use (or at least the great majority has). Judging from this email it wasn't the intention just to drop your efforts with the flip of a switch but it just happens to be bad timing; if you could have offered it three weeks ago everything would have been fine. You are free to offer the model on your own (many aircraft developers to this for one reason or another) and I for one am pleased to see others to step up to improve upon our current aircraft. So I would advise to try to get it included just after the new release and then when the 2.6 release is in feature freeze you could still get bug fixes included (which are probably minor compared to a complete overhaul). > To please to the users, our model will be ever checked against an FG > stable version. > We will start that rule with FG 2.4, offering our models within our > pages, but, under an other license. I have tot state that it is not allowed to change the license unless: * everything you use is your own work * or you're moving to a more restrictive license that is still open source (which is hard in case of the GPL). Erik -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GCC options
On Fri, 2011-07-15 at 21:27 -0700, John Wojnaroski wrote: > Hi Curt, > > Silly question, if you have a moment... > > Want to change the compiler option. Tried ./configure CFLAGS=-O3 but > seemed to have no effect > > if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src > -I/usr/local/include -g -O2 -D_REENTRANT -MT air > > something stepping on the configure option?? CFLAGS is for the C compiler while FlightGear almost exclusively uses the C++ compiler: Try runining: ./configure CXXLAGS=-O3 CFLAGS=$CXXFLAGS By the way, I'm using: CXXFLAGS="-g -Os -Wall -Werror=format-security -march=native -mtune=native" Erik -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New urban shader
Hi, I always wondered why the new urban shader brought my system to it's knees. It turned out that with the quality lever above 3.5 he urban shader and the landmass shader for urban areas were both active ... I now get an acceptable 21 fps (was way below 10fps) for the urban shader and a good 42 fps for the landmass city bump shader. Erik -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dull license question
On Sat, 2011-07-16 at 16:18 +0100, Stuart Buchanan wrote: > Hi Guys, > > While thoroughly enjoying the PC9-M, I noticed that its license is GPL v3. > > >From a very cursory browse of the "Quick Guide to GPLv3", > (http://www.gnu.org/licenses/quick-guide-gplv3.html) GPL3 is > apparently compatible with GPL2, but I'm not clear if we can > distribute a GPL3 aircraft as part of an FG distribution which is > otherwise GPL v2. The base package is GPL v2 or later. I wouldn't worry too much about it since the base package that gets distributed only contains a handful of aircraft. Erik -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] how to compile old and small fgfs
On Sun, 2011-07-24 at 00:17 -0700, Fgfs Fgfs wrote: > Hi > anyone has compiled an old fgfs alike 0.8? > I'm running into such: > > Point3D’ was not declared in this scope > etc. > > > probably i find out but maybe someone could help me out? If you really want to go that path then you'll need matching versions of SimGear and plib. I believe Point3D was in SimGear. Erik -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Martin is responding slowly ....
On Mon, 2011-07-25 at 17:14 +0200, Martin Spott wrote: > Hi, if anyone is wondering why I'm responding even slower as usual, > this might be caused by the simple fact that I'm being distracted by > our daughter who was given birth last night. Congratulations Martin! Erik -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The state of things in Flight Gear
On Wed, 2011-07-27 at 13:17 +0400, Slavutinsky Victor wrote: > Guys, I had made my conclusions. It seems I am leaving. > > On my view situation in FG is: > > 1) Closed upper society have intention to make profit by Flight Gear > finally, maybe have some little profit right now. > 2) Intention to include someone else in that society is absented in it > of course. > 3) Plans of future development is existed but in hide, otherwise folks > could realize what they are used. > 4) Guys who understands that leaving the project. Commonly they get > pressed out by intrigues before realization. > 5) Complexity of code produced by that path grows in geometrical > progression with size and it could not be reorganized and documented. > Therefore the far it goes the less possibility to find and eliminate > errors, even for group of developers, and less the possibility to > include someone else in that group. In time it will come to the dead end > if it will develop by that path further. I'm afraid that you wrongly interpret 'being busy doing other things' with 'unwilling to help'. So far everybody who has made valuable contributions has been welcomed by everybody. And depending on the time someone has/is willing to reserver for FlightGear there's always a chance of getting help, but sometimes it is required to ask for it more than once to gain some attraction. That has nothing to do with who is asking but more about what is being asked, how much time it takes to explain and the amount of knowledge for every developer about the particular subject. It's your choice to leave off course but it would be sad to do it on the wrong assumptions. Erik -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Sat, 2011-08-06 at 14:43 +0300, thorsten.i.r...@jyu.fi wrote: > Some visual impressions from the 3 cloud types I've converted to the new > system so far here: > > http://www.flightgear.org/forums/viewtopic.php?f=5&t=7358&start=390#p132335 > > Stuart - please help: I get anti-shadowing for Stratus clouds, and I don't > really understand why... Could this be a normal map problem (I believe it's possible to store the normal map in dds textures) Erik -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Inputs
On Sun, 2011-08-07 at 20:33 -0400, Derrick Washington wrote:
> Hi
>
>I need to know if the inputs coming from FG, while using a generic
> protocol having binary mode set to true, are coming in as integers
> that need to be converted to floating point or is FG actually sending
> in a floating point word, a byte at a time? So my code to receive FG
> data looks something like this
>
>
> for ( int i = 0; i <= 3; i++ ) { dummy_var = (dummy_var << 8) |
> rs232_uart1; }
>
>
>
> return ( (float) dummy_var);
>
> What I am wondering is, is the " return ( (float) dummy_var); " cast
> to a float necessary, or is the number already in floating point
> format, if so then I need to instruct my hardware to retrieve a full
> word at a time. I've included the xml file just in case you guys have
> any questions about what data I am asking FG to transmit.
Floats are sent as floats and (depending on which version of FlightGear
you're using, doubles as doubles but they where added in a later
version).
BTW you can (and have to) specify a separate section for input and for
output in the same protocol configuration file if you want
bi-directional communication.
Erik
--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Inputs
On Mon, 2011-08-08 at 07:20 -0400, Derrick Washington wrote: > Hi Erik > > Thanks for the input, by the way I thought that bidirectional > transmission was unsupported. I tried to put both my input and > outputs in the same xml file and choose bi directional support but I > keeping getting an error message saying that bidirectional support is > not supported, I have included the .xml file I've been using so you > can take a look is there something that I'm doing wrong? Checking the code .. you seem to be right. I'm not sure if it's just a matter of no one tried it yet and hence the protective code. You might want to try to comment out the lines starting at line 66 of FlightGear/src/Network/generic.cxx en see if it works anyhow. Erik -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to turn off the 3D cockpit
On Mon, 2011-08-08 at 08:09 -0700, Gene Buckle wrote: > On Mon, 8 Aug 2011, syd adams wrote: > > > Its in the property tree , you can open the property browser and > > change the value there , or you could add it to the -set.xml file like > > i do: > > > > true > > > > > > I wonder if this kind of thing would be a good candidate for inclusion in > the fgrun tool? In a way you already can, it's possible to define a property value at startup: fgfs --prop:/sim/allow-toggle-cockpit=0 --prop:[type:]name=value Set property to . can be one of string, double, float, long, int, orstring, double, float, long, int, or bool. And I believe fgrun allows one to add custom startup arguments. Erik -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sun & Light placement
On Thu, 2011-08-18 at 12:32 +0300, Emilian Huminiuc wrote: > http://www.heavens- > above.com/sun.aspx?lat=50.81982&lng=-0.14282&loc=Unspecified&alt=0&tz=BST Yeah it's probably not the sun position but rather the sky dome coloring code that's the problem. Erik -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Hi res textures
On Thu, 2011-08-18 at 21:57 -0700, John Wojnaroski wrote: > How does one specify use of high res textures? > > Or is this an "auto-select" feature during startup based on driver and > graphic card features High resolution textures take precedence over low resolution textures when available. The usual procedure to only use low resolution textures was to rename Textures.high Erik -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Slackware packages for 2.4.0
On Sun, 2011-08-21 at 14:32 -0500, Curtis Olson wrote: > > Also, we have older packages that were available for Sun, sgi, and > FreeBSD. Can anyone comment on the latest package versions available > for these platforms and if we still want to list them on our download > page? Who's going to be the first to come out with an Android > package? :-) Android (ARM) won't work since ARM only supports float´s in hardware and not double's. Erik -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CHMOD 0755 on some files
On Sun, 2011-09-11 at 12:13 +0200, Roland Häder wrote: > Hi, > > with recent commit there have been changed CHMOD from 0644 to 0755 on > some files. Here is the full list I have seen: I seem to recall this happened to me before, how does that happen? I've just copied them from the JSBSim source files and would have expected the mode to be unchanged. Erik -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CHMOD 0755 on some files
On Sun, 2011-09-11 at 13:28 +0200, Roland Häder wrote: > On Sun, 2011-09-11 at 13:16 +0200, Erik Hofman wrote: > > I seem to recall this happened to me before, how does that happen? > > I've just copied them from the JSBSim source files and would have > > expected the mode to be unchanged. > Hi, > > do you use Windozer or so? If yes, that might be the reason. When > Windows copies, creates or just saves files, the permissions got set to > 0755 on files and 0777 for directories. I'm not but Jon (the author) is, so that could explain why they're in CVS that way. Ok, now I understand. Erik -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Sun, 2011-09-11 at 23:18 +0100, Stuart Buchanan wrote: > On Sun, Sep 11, 2011 at 7:47 AM, Thorsten Renk wrote: > >> I'd really like the 3D cloud infrastructure to be used for all the > >> clouds, so > >> if there are features missing we should address them. > >> > >> Would it be possible to modify the 3D clouds so that they can be used for > >> the rain texture as well? For example, I could provide a sprite > >> distribution > >> on the surface of a cylinder rather than a sphere if that would help. > > > > Just a short answer to this part: All these objects (rain textures, Cirrus > > clouds,...) do not use the 3d cloud infrastructure because they are not 3d > > clouds. > > Thanks for the explanation. Doesn't look like there's much benefit from > hacking the 3D clouds system to do something it's not intended to. > > So... that leaves fixing the underlying problem. > > The problem definitely seems to be that any other objects in the scenery with > an alpha layer are rendered after the clouds, so are rendered in front of > them, > irrespective of the viewpoint and their relative positions. By > removing the alpha > layer from the texture of the stratosphere-tower in Las Vegas, I was > able to work > around the problem. > > Unfortunately, fixing this is going to require someone with more knowledge of > OSG than I have. The problem is that the 3D clouds are in an earlier > rendering bin > from the scenery models with transparent textures, which means that the > clouds > are rendered first in their entirety, and then the scenery models, with no > consideration of the relative position (i.e. depth) compare with the clouds. > This was done for perf reasons. Putting the clouds in the same rendering bin > (i.e. TRANSPARENT_BIN) halves the framerate on my system. > > I'm not sure there is a fix for this that doesn't massively impact > performance, unless > we add some of these objects to the CLOUDS_BIN and then depth-sort them within > the cloud code itself which depth-sorts slowly across multiple frames > to avoid exactly > the performance hit from depth sorting the entire TRANSPARENT_BIN in > each frame. > > Tim/Matthias - care to comment? I've once applied a patch someone came up with that fixed a number of alpha blending problems but unfortunately can't find where it applied. In the mean time I found this: http://www.palomino3d.com/pal_com/openscenegraph/ Blending Blending in OSG is similar to OpenGL, with the addition of using OSG's transparent bin (essentially another rendering pass) for transparent primitives. // Enable blending, select transparent bin. stateSet->setMode( GL_BLEND, osg::StateAttribute::ON ); stateSet->setRenderingHint( osg::StateSet::TRANSPARENT_BIN ); // Enable depth test so that an opaque polygon will occlude a transparent one behind it. stateSet->setMode( GL_DEPTH_TEST, osg::StateAttribute::ON ); // Conversely, disable writing to depth buffer so that // a transparent polygon will allow polygons behind it to shine thru. // OSG renders transparent polygons after opaque ones. osg::Depth* depth = new osg::Depth; depth->setWriteMask( false ); stateSet->setAttributeAndModes( depth, osg::StateAttribute::ON ); // Disable conflicting modes. stateSet->setMode( GL_LIGHTING, osg::StateAttribute::OFF ); Erik -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Sun, 2011-09-11 at 23:18 +0100, Stuart Buchanan wrote: > Unfortunately, fixing this is going to require someone with more knowledge of > OSG than I have. The problem is that the 3D clouds are in an earlier > rendering bin > from the scenery models with transparent textures, which means that the > clouds > are rendered first in their entirety, and then the scenery models, with no > consideration of the relative position (i.e. depth) compare with the clouds. > This was done for perf reasons. Putting the clouds in the same rendering bin > (i.e. TRANSPARENT_BIN) halves the framerate on my system. Oh wait, I missed this part. Sorry. Erik -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Repeatable random seeds
On Wed, 2011-09-14 at 11:18 +0200, Andreas Gaeb wrote: > Hello everybody, > > lately I've been working on a multiscreen setup driven by multiple host > machines. In order to get the same random scenery objects, all machines > need to use the same random seed. Up to now, the random seed is taken > from system time, which leads to inconsistencies. Is this broken.. again? Sigh. I've been pushing this behavior various times and scenery objects should always be positioned at the same location over and over again. This has been fixed a number of times with a proper solution. This patch is not a proper solution, sorry. Erik -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Repeatable random seeds
On Wed, 2011-09-14 at 13:33 +0200, Andreas Gaeb wrote: > Am 14.09.2011 11:43, schrieb Erik Hofman: > > I've been pushing this behavior various times and scenery objects should > > always be positioned at the same location over and over again. > To clarify things up a bit, not all is broken: > - Houses etc. are the same > - Trees are at the same location and same size, but sometimes have > different textures. Looks like this is called by a rand() call in > TreeBin.cxx:256, which is probably there because sg_random doesn't have > an integer rand function. > - both 2D and 3D clouds differ, and as far as I can tell, both in > position and texture. Ah ok, then I guess it's better to address those different items instead of trying to create a reproducible wind gust (for instance) ;-) Erik -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Repeatable random seeds
On Fri, 2011-09-16 at 13:22 +0200, Csaba Halász wrote: > On Fri, Sep 16, 2011 at 10:35 AM, Andreas Gaeb wrote: > > > > However, the sg_srandom_time_10() function also looks appealing. That > > would give the same random seed for all processes started within the > > same 10 minute interval, yet also vary every 10 minutes even with the > > same METAR. Maybe even METAR updates are possible if an update re-seeds > > from that function. > > Ideally, we want MP to be synchronized too, and also if you restart FG > on one of the machines it should pick up the same random stream again. sg_srandom_time_10() divides the time in chunks of 10 minutes, so if there is a mismatch the first time it will get corrected the next time. Erik -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fairly recent change in sun/view position code?
Hi, Has anything changed in the viewer or sun positioning code in the last year or so? I've been trying to hunt down why the fog/skydome brightening effect is misaligned with the sun position and basically concluded the following line at libe 451 of Time/light.cxx is the cause _sun_rotation = atan2(local_sun_vec.x(), -local_sun_vec.y()); But that line has been there for a very long time..? Erik -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fairly recent change in sun/view position code?
On Sat, 2011-09-24 at 13:46 +0200, Frederic Bouvier wrote: > Hi Erik, > There was a misalignment in the water shader between the sun and > its reflection in the water that Tim fixed. See issue #182 > (http://code.google.com/p/flightgear-bugs/issues/detail?id=182) > > His commit seems to be this one : > https://gitorious.org/fg/flightgear/commit/79a2173ef9d6d04af8815d658c0a4daedf553ac4 > > If you change something in that area, please be sure that the water shader is > still ok Ok thanks for the hints. Erik -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fairly recent change in sun/view position code?
On Sat, 2011-09-24 at 15:03 +0200, Erik Hofman wrote: > On Sat, 2011-09-24 at 13:46 +0200, Frederic Bouvier wrote: > > Hi Erik, > > > There was a misalignment in the water shader between the sun and > > its reflection in the water that Tim fixed. See issue #182 > > (http://code.google.com/p/flightgear-bugs/issues/detail?id=182) > > > > His commit seems to be this one : > > https://gitorious.org/fg/flightgear/commit/79a2173ef9d6d04af8815d658c0a4daedf553ac4 > > > > If you change something in that area, please be sure that the water shader > > is still ok > > Ok thanks for the hints. Alright I have no clue what's going on there without diving deep into the different coordination systems which takes way more time than I can afford right now. It would be nice if Tim Moore could also fix the fog/skydome misalignment he introduced. Erik -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fairly recent change in sun/view position code?
On Sat, 2011-09-24 at 15:29 +0200, Frederic Bouvier wrote: > > It would be nice if Tim Moore could also fix the fog/skydome > > misalignment he introduced. > > It's a bit harsh as the previous code was also buggy It wasn't meant to be harsh but the old code worked for more than 10 years. Some problem only arose when the water reflection shader was introduced. Erik -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest JSBsim update
On Mon, 2011-09-26 at 09:25 +0100, Alan Teeder wrote: > > I´m not sure what is meant with these lines of code in DGWinds.cpp at > line 286, and neither is MSVC Winking smile Is it a patch gone > wrong? > > Alan > > sig_p = 1.9/sqrt(L_w*b_w)*sig_w, // Yeager1998, eq. (8) > <<< FGWinds.cpp > //sig_q = sqrt(M_PI/2/L_w/b_w), // eq. (14) > /// sig_r = sqrt(2*M_PI/3/L_w/b_w), // eq. (17) > === > //sig_q = sqrt(M_PI/2/L_w/b_w), // eq. (14) > //sig_r = sqrt(2*M_PI/3/L_w/b_w), // eq. (17) > >>> 1.5 > L_p = sqrt(L_w*b_w)/2.6, // eq. (10) It looks like I need to check my CVS copy of JSBSim... Thanks for the report. Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal and javascript..
On Fri, 2011-10-07 at 02:30 +0100, Peter Morgan wrote: > How does nasal works within the sim.. ? Excellent, it can handle weather simulation and rendering just well. > why we can not use a "ecma" scripting engine ? > Can i Use javascript in FG, smells the smae almost... > > I can embed nasal within an xml tag?? No, javascript is unsupported, just like any of it's predecessors or look-alikes. At one point I had javascrip[t working but Nasal is just much better suited for FlightGear because of it's size, processing speed and because a number of developers have a good idea what's going on. > Why can we use V8 which is a fast scripting engine.. its rumoured.. In theory we could even use VBScript but Nasal has proven to be valuable for almost 10 years, so no reason to change or add another scripting language. Besides, if you know JavaScript then learning Nasal would take little effort. Erik -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud shadows
On Fri, 2011-10-07 at 10:14 +0100, James Turner wrote: > On 7 Oct 2011, at 09:47, thorsten.i.r...@jyu.fi wrote: > > > Sorry, I'm just getting a bit touchy about reading 'we need' - I've had > > too much of that recently. > > 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.. Erik -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Skydome and Terrain shader with haze - some helprequired
On Tue, 2011-10-11 at 09:30 +0100, Vivian Meazza wrote: > Thorsten > > > Im the last weeks, I've been working on integrating Lauri's skydome > > scattering shader in a seamless way with the rest of the environment. I > > have now a working version of the shaders available which could be > > committed. > Looks like you are doing things the hard way. Emilian and I are busy > rationalizing, and combining and improving shaders as appropriate right now: > we would be happy to add your stuff to the pile. > > You could do a merger request to our sandbox here: > > https://gitorious.org/fgdata-textures-ng/fgdata-textures-ng > > Or post the files somewhere that we can get them, or email them as an > attachment to me. I can't promise an instant solution, because we already > have a heavy workload in FG and RL, but we can take a look. Let me state that all of you are doing an excellent job! FlightGear keeps getting better by the day and I see leaps of progress just in a few months. Great work. Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On Sat, 2011-10-22 at 16:03 +0100, James Turner wrote: > If there's lingering queries about Cmake, or requests on the 'best' way to > handle the transition, please let me know. Feedback on the README file would > be appreciated too, or even commits / patches to improve it! CMake worked like a charm but I did notice that the special purpose FDM's don't get included anymore. I believe I did see it mentioned in the CMake configuration but leaving code out on a development system might introduce a chance of bit-rot. That said, I think some of the SP FDM's can be removed entirely since they've been superseded. Erik -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On Sun, 2011-10-23 at 09:44 +0100, James Turner wrote: > The special purpose FDMs are disabled by default, it's one line to make them > enabled by default of course! > > Actually, one of my post CMake build plans, is to make all the FDMs > switchable at build-time, partly because I'm sick of all the compiler > warnings from the UIUC / larcsim code, but also because at some point in the > future we want the FDMs to be more 'modular' to the rest of FG - eg in their > own thread or HLA-process, potentially. Knowing that the code builds cleanly > with, for example, *just* the Null/UFO FDM selected would be interesting. We had been thinking about that in the past but with the lack of a build server we decided that leaving them all in was the safest option. > > So we will have ENABLE_YASIM, ENABLE_LARCSIM, ENABLE_JSBSIM and so on. > Obviously I will keep the defaults for those to match the current > expectations (well, maybe Larcsim could be off by default? Does anyone ever > use it?) I believe UIUC uses LaRCsim. I agree the UIUC code is becoming a problem since they used to develop in in house and dump a bunch of code in the FlightGear tree when there was still development in that area. I must admit I don't have a clue if we even are allowed to change or fix the UIUC code, and if there is a chance changes get overwritten when they decide to push another round of updates... > But you've convinced it's a good idea to have a Jenkins build, which has all > the FDMs enabled, to avoid bit-rot in the special ones! Ah great. Erik -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terrain incompatibility with current terragear libs
On Sat, 2011-11-05 at 13:23 +0100, Eric van den Berg wrote: > Hello everyone, > > I am currently making some Terrain around ELLX using SRMT4 and CORINE > data. For that I used a current (approx. two weeks old) terragear > version, compiled against PLIB, OSG ans SIMGEAR of the same age. > > The Terrain generated works fine with current FG GIT, but gives errors > with both FG 2.0 and 2.4. If starting on these tiles, FG hangs at > start-up (indefinately) and flying to these tiles gives the error: "We > detected an error while reading the file." for each tile FG tries to load. > > So I re-compiled terragear against the FG 2.4.0 PLIB, OSG and SIMGEAR > versions...problem solved. Terrain works for all FG versions again. > > Not sure if this is a known issue, so I thought I'd share, There have been changes to both TerraGear and SimGear to be able to handle more detailed terrain. I assume this is one of the side effects. Erik -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Call for Betatesters (OpenAL Linux)
Hi, Some of you might already be aware of the fact that have been developing a 3D audio library for quite some time. Now is the time to call for a larger group of beta testers. The software is a replacement for OpenAL on linux and consists of two components: 1. the AeonWave Audio eXtentions library (or AeonWave for short). 2. an OpenAL emulation layer library. AeonWave has a quite extensive features list (many supported data formats, several filters and effects, sub-mixing capable audio-frames to name a few) but the most important feature for OpenAL (and for FlightGear users at this time) is that it can render sound sources 5 to 7 times faster than either OpenAL-Soft or OpenAL-Sample. This leaves more CPU power for simulation and graphics rendering. AeonWave comes in two variants; the Lite version (limited but free) is a great start for OpenAL enabled software, and the HD version which is not yet offered but will not be free of charge (the price will be sub $10,- though). Anyone who is willing to give it a try can get the software from: http://www.adalin.com Download and install AeonWave and AeonWave-OpenAL and you are ready to go. Any other software is optional. Please don't reply here if you wish to give feedback but reply to me directly (preferable with AeonWave in the subject) Any help would be highly appreciated! Erik -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
On Mon, 2011-11-07 at 18:26 +, James Turner wrote:
> On 7 Nov 2011, at 17:07, Martin Spott wrote:
>
> > Ok, I conclude: "LIB_POSTFIX" im Simgear doesn't work as expected ;-/
>
> I think we have a 'thinko' in the module - looking at the code, we're using:
>
> install (TARGETS ${libName} ARCHIVE DESTINATION lib${LIB_SUFFIX})
>
> ... my guess is if this was LIB_POSTFIX instead, it would do exactly what you
> want ... set it to '64' and simgear will install to lib64
>
> But I also suspect there's a smarter, automatic way to deal with this by
> default.
There is:
IF(CMAKE_SIZEOF_VOID_P MATCHES "8")
SET(LIB_POSTFIX "64" CACHE STRING "suffix for 32/64 dir placement")
MARK_AS_ADVANCED(LIB_POSTFIX)
ENDIF()
IF(NOT DEFINED LIB_POSTFIX)
SET(LIB_POSTFIX "")
ENDIF()
Erik
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
On Tue, 2011-11-08 at 11:07 +0100, Arnt Karlsen wrote: > On Tue, 08 Nov 2011 10:03:42 +0100, Erik wrote in message > > IF(CMAKE_SIZEOF_VOID_P MATCHES "8") > > SET(LIB_POSTFIX "64" CACHE STRING "suffix for 32/64 dir placement") > > MARK_AS_ADVANCED(LIB_POSTFIX) > > ENDIF() > > IF(NOT DEFINED LIB_POSTFIX) > > SET(LIB_POSTFIX "") > > ENDIF() > > > > Erik > > ..and this still gives us the ability to call > our binaries e.g. fgfs-w-sdl-wo-osg? Sure it should only affect the libraries being build and installed Erik -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] how to change airplane/environment/conditions using FG 2.4.0
On Wed, 2011-11-09 at 11:02 +0800, roger phil baker六 wrote: > hello, > > i have succeeded in building FG 2.4.0 using MS VS 2008, but the > executable fgfs.exe only directs to the game with Cessna > > without "FlightGear Wizard" which can select airplanes, airports, and > other environmental conditions before the flight starts. > > is there any other source code for select interface? > > does anyone can figure out how to find change > airplane/environment/conditions using FG 2.4.0 ? It's called fgrun: http://sourceforge.net/projects/fgrun/ Erik -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing fgfs-construct crashes
On Sun, 2011-11-13 at 11:02 +, Martin Spott wrote: > James Turner wrote: > > > Looks very good to me - especially when it's combined with some of > > the shader / materials work that is coming! > > Ah, well, I'm having mixed feelings about the shaders because they're > imposing a huge performance hit onto our bigger multi-monitor setup Did you try to lower the effects lever to below 4.0? The more sophisticated city shader brings my system to it's knees but the old city shader gives a solid 60fps for me. Notice that lowering the lever may cause a shader bug which is fixed when restarting flightgear (city areas might disappear). Erik -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] make data-tar
On Mon, 14 Nov 2011 14:14:28 -0600 Curtis Olson wrote: > Does anyone know if the "make data-tar" target got carried over some how to > the new flightgear cmake build system? I could recreate this as a shell > script and maybe that's a better way to do this, but I don't want to > reinvent the wheel. (I'm working on rolling out another dev snapshot > release, but I depended on make data-tar in the old automake system so I > need to find out where that went or recreate it somehow before I can > proceed.) 'make package' creates debian packages and rpm packages and 'make package_source' create a .zip and a .tar.gz archive. Erik -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reminder for the release process for version
On Sat, 2011-11-19 at 18:47 +1100, George Patterson wrote: > Considering the last release was August, what's to be gained by > another release in the next couple of months? > What would be on the Release feature List of improvements? Well I've seen some pretty impressive shader and landclass geometry improvements (not to mention better and faster weather integration) lately. Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reminder for the release process for version
On Sat, 2011-11-19 at 10:55 +, Martin Spott wrote: > Erik Hofman wrote: > > > Well I've seen some pretty impressive shader and landclass geometry > > improvements [...] > > Landclass geometry ? You mean texture coordinate size ? Actually I meant the addition of curved taxiways and the ability to store larger chunks of geometry (64-bit pointers?). Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reminder for the release process for version
On Sat, 2011-11-19 at 11:13 +, Martin Spott wrote: > Erik Hofman wrote: > > > Actually I meant the addition of curved taxiways [...] > > Well, that's TerraGear and thus mostly unrelated to the release cycle > of SimGear/FlightGear, especially as long as the respective developers > consider their work as being too experimental even to put it into a > _branch_ of "terragear-cs" :-) I know, I know. But it still looks pretty impressive. Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Sounds for AI models (first step implemented)
Hi, I've been working on implementing an FGFX class for AIModels and am pretty much done (I think) except for one final step; I have a hard time figuring out how to get the sound/path property from an AI XML configuration file. The path needs to be set in src/AIModel/AIBase.cxx line 317 (updated code in git). It would be nice if someone more familiar with AI traffic can give me a hint on how to proceed. Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sounds for AI models (first step implemented)
On Sun, 2011-11-20 at 16:49 +0100, ThorstenB wrote: > Am 20.11.2011 15:40, schrieb Erik Hofman: > > I've been working on implementing an FGFX class for AIModels and am > > pretty much done (I think) except for one final step; > > That literally sounds like a great new feature :). > > Oh, since we've already been discussing various performance issues > today: would it make sense to add an "AI sound" property switch (and a > switch in the main sound dialog), so this is optional? > > Not sure what kind of performance impact you expect, but we have > airports with loads of AI traffic (hundreds of aircraft) - so maybe this > could cause issues, once sound effects are added to the AI aircraft XMLs... No problem, but there is already a limit on the number of sources that are available through OpenAL. But I agree this is something that needs to be looked after one way or another (setting a distance limit is another option). Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sounds for AI models (first step implemented)
On Sun, 2011-11-20 at 16:04 +0100, Durk Talsma wrote: > Hi Erik, > > I'll try to have a look next week, although admittedly, the relation between > the AI models code and the property tree is not really the stuff I'm > intimately familiar with. Thanks, I'll also keep searching in the mean time. Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Announce: AeonWave 2.1 for Linux available
Hi, On Mon, 2011-11-07 at 12:53 +0100, Erik Hofman wrote: > Some of you might already be aware of the fact that have been developing > a 3D audio library for quite some time. Now is the time to call for a > larger group of beta testers. > > The software is a replacement for OpenAL on linux and consists of two > components: > > 1. the AeonWave Audio eXtentions library (or AeonWave for short). > 2. an OpenAL emulation layer library. This is an update to inform everyone that AeonWave version 2.1 has officially been released at: http://www.adalin.com The Lite version is still (and will always be) royalty-free and the OpenAL layer is released under the terms of LGPL v3. Unfortunately I seemed to have goofed with the naming of RPM packages so Redhat/Fedora users might need to remove the beta install prior to installing the official version, sorry for that. Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
