Re: [Flightgear-devel] hypothetical gpl question
On Mon, 2009-03-16 at 20:30 -0500, Curtis Olson wrote: > Here's a hypothetical question. > > Let's say some company "A" builds an internal product prototype that > incorporates FlightGear as part of a larger aggregate system. Murky waters here. And a slippery slope to be on. > Let's say they even make a few small changes to FlightGear. Now they > give away a demo system This is distributing. If there were no changes simply pointing to the FG source at cvs.flightgear.org would be sufficient. However, as they distributed a modified executable, they owe the community the modified sources to that executable. That is simply the "cost" of using flightgear. > to a couple different potential customers and say, "Hey what do you > think." They haven't rolled out an actual product, they haven't had > any actual sales. No customer has paid any money for the copy of the > system. > > Has the GPL been violated? Probably. >From the GPL v2 license preamble: Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. "You" above refers to both company "A" and the potential customers that received flightgear from company "A." Company "A" has the freedom to sell copies of a modified flightgear. The potential customers have a right to the modified source code, and the freedom to further distribute the modified sources and binary. "You" above also applies to anyone who receives a copy of the modified flightgear. So if company "A" is distributing a modified binary copy of flightgear without offering the modified sources, they have violated the GPL. IANAL, Ron -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hypothetical gpl question
Curtis Olson wrote: > Now they give away a demo system to a couple different potential > customers and say, "Hey what do you think." They haven't rolled out > an actual product, they haven't had any actual sales. No customer has > paid any money for the copy of the system. > > Has the GPL been violated? Probably, if they have distributed it to people outside of their organisation, even for "demo" purposes, money or lack of isn't of importance, so the only question is: Is their work a derivative, or are they merely aggregating it into a distribution of softwares. If their work depends on the presence of flightgear, I think that's really a derivative. If flightgear can be removed and the system still used (eg their system can export models that flightgear can use, oh and here is flightgear on the same CD to save you downloading it) then could just be aggregation, but even still linking to it (in terms of library) at all causes an issue. Murky water lies therein. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hypothetical gpl question
On Tue, Mar 17, 2009 at 12:30 PM, Curtis Olson wrote: > Here's a hypothetical question. > > Let's say some company "A" builds an internal product prototype that > incorporates FlightGear as part of a larger aggregate system. Let's say > they even make a few small changes to FlightGear. Now they give away a demo > system to a couple different potential customers and say, "Hey what do you > think." They haven't rolled out an actual product, they haven't had any > actual sales. No customer has paid any money for the copy of the system. > > Has the GPL been violated? > Hi Curt, I believe that as the software has not been released, this would be the same as an software developer extending some software. As long as the product hasn't been provided to the customer then everything is okay. It's only when you have sold the software that you are required to provide access to the software to that customer. Having said that, if the company above are supplying the demo on installation media, then the above doesn't apply and the GPL has been violated. Regards George -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] hypothetical gpl question
Here's a hypothetical question. Let's say some company "A" builds an internal product prototype that incorporates FlightGear as part of a larger aggregate system. Let's say they even make a few small changes to FlightGear. Now they give away a demo system to a couple different potential customers and say, "Hey what do you think." They haven't rolled out an actual product, they haven't had any actual sales. No customer has paid any money for the copy of the system. Has the GPL been violated? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ..1.0.2 "./makefg NOPAUSE DOUPD" SG compile fails: undefined reference to `clock_gettime'
On Mon, 16 Mar 2009 02:11:38 +0100, Arnt wrote in message <20090316021138.3368a...@a45.fmb.no>: > Hi, > > ..I get this compile error with Geoff's 1.0.2 ./makefg NOPAUSE DOUPD": ..1.0.3 fails in exactly the same way, /opt/bygg/fg/tmp/templog1.txt is attached: a...@a45:/opt/bygg/fg $ ll \ /opt/bygg/fg/tmp/templog1.txt &&md5sum /opt/bygg/fg/tmp/templog1.txt -rw-r--r-- 1 arnt arnt 3803 Mar 16 23:14 /opt/bygg/fg/tmp/templog1.txt 8db9161471b0e44388714493abe941fa /opt/bygg/fg/tmp/templog1.txt a...@a45:/opt/bygg/fg $ > /opt/bygg/fg/install/simgear/lib/libsgtiming.a(timestamp.o): > In function `SGTimeStamp::stamp()': > /opt/bygg/fg/simgear/source/simgear/timing/timestamp.cxx:79: > undefined reference to `clock_gettime' > /opt/bygg/fg/simgear/source/simgear/timing/timestamp.cxx:76: > undefined reference to `clock_gettime' > collect2: ld returned 1 exit status > make[2]: *** [fgfs] Error 1 > make[2]: Leaving directory `/opt/bygg/fg/fgfs/source/src/Main' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/opt/bygg/fg/fgfs/source/src' > make: *** [all-recursive] Error 1 > -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. Processing makefg, with command [NOPAUSE DOUPD] makefg: Running in LSB Version: core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:cxx-3.0-ia32:cxx-3.0-noarch:cxx-3.1-ia32:cxx-3.1-noarch:cxx-3.2-ia32:cxx-3.2-noarch:desktop-3.1-ia32:desktop-3.1-noarch:desktop-3.2-ia32:desktop-3.2-noarch:graphics-2.0-ia32:graphics-2.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:graphics-3.1-ia32:graphics-3.1-noarch:graphics-3.2-ia32:graphics-3.2-noarch:languages-3.2-ia32:languages-3.2-noarch:multimedia-3.2-ia32:multimedia-3.2-noarch:printing-3.2-ia32:printing-3.2-noarch:qt4-3.1-ia32:qt4-3.1-noarch Distributor ID: Debian Description: Debian GNU/Linux unstable (sid) Release: unstable Codename: sid Checking 2 arguments ... [NOPAUSE DOUPD] All aguments ok. Will process: [ PLIB OSG SG FG FGRUN] The script pauses for input of a 'y' frequently. Any other input, or none, and it will exit. QUESTION? QUESTION? QUESTION? QUESTION? *** THIS APPEARS TO BE A NEW INSTALLATION in [/opt/bygg/fg] *** Are you sure you want to continue? Doing tool and package update... package update... The following should NOT be required, but with the present SG/FG it is! Will do 'sudo apt-get install libopenthreads6' Continue to update these? Done tool and package update. Continue? WARNING: This is a NEW installation in the [/opt/bygg/fg] directory! Create the install directory install? Processing PLIB ... PLIB checkout with svn co http://plib.svn.sourceforge.net/svnroot/plib/trunk plib Doing PLIB checkout of trunk ... moment... Done plib checkout. Force SG/FG AUTO and CLEAN Running autogen.sh in /opt/bygg/fg/plib... Done PLIB autogen.sh. Proceed? Running ./configure --prefix=/opt/bygg/fg/install/plib --exec-prefix=/opt/bygg/fg/install/plib Done PLIB configure. Proceed? Creating PLIB install in /opt/bygg/fg/install/plib... Done PLIB make. Continue to install? Done all PLIB. Proceed? Processing OpenSceneGraph ... Doing svn donwload of trunk ... moment ... Done OSG svn checkout ... As this a FRESH checkout, you may have to run this script again, to get OpenThreads, and other things to build correctly... Done CO or UPD. Proceed with cmake? NOTE WELL: Read the above CAREFULLY. It may contain warnings, and important advice. Done cmake 1. Proceed to cmake with definitions? Running cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_CXX_FLAGS=-O3 -D CMAKE_C_FLAGS=-O3 -D CMAKE_INSTALL_PREFIX:PATH=/opt/bygg/fg/install/OpenSceneGraph . Done cmake with definitions. Proceed to make? Done make. Proceed to install? WARNING: OSG directory [/opt/bygg/fg/install/OpenSceneGraph/lib64] does NOT exist! Done OSG. Proceed? Processing simgear/source ... Doing SG CVS checkout... moment... CVS password: guest Done SG checkout. Done SG CO or UPD. Proceed with autogen.sh Running autogen.sh in /opt/bygg/fg/simgear/source... Done SG autogen.sh. Proceed with configure? Doing SG ./configure --prefix=/opt/bygg/fg/install/simgear --exec-prefix=/opt/bygg/fg/install/simgear --with-osg=/opt/bygg/fg/install/OpenSceneGraph --with-plib=/opt/bygg/fg/install/plib --with-jpeg-factory Done SG ./configure. Continue? Done SG configure. Proceed with make clean? Done SG make clean. Proceed with make? Done SG make. Proceed to install? SG all done. Continue? Creating fgfs directory Doing FG source checkout... moment... Done FG source check out ... Done FG CO or UPD. Proceed? Running autogen.sh in /opt/bygg/fg/fgfs/source... Done FG autogen.sh. Proceed to configure? Doing FG ./configure --prefix=/opt/bygg/fg/install/fgfs --exec-prefix=/opt/bygg/fg/install/fgfs --with-osg=/opt/bygg/fg/install/OpenSceneGraph --with-simgear=/op
Re: [Flightgear-devel] OpenStreetMap Open Database License
Why not simply ship scenery compiled with the osm data under a different license? On Mon, Mar 16, 2009 at 7:10 AM, Martin Spott wrote: > Jon Stockill wrote: > > Tim Moore wrote: > > > >> Obviously you've been following this more closely than I, but doesn't > the > >> proposed license specifically allow the use of OSM data in applications > >> like flight simulators, with a fairly liberal license? > > > > I originally added the use case - it's been tweaked slightly since then, > > and is currently awaiting a response from the lawyer. Not really much > > to do until that decision materialises. > > Well, neither the former nor the current wording of the "computer game" > use case actually reflect the process of extracting road data from the > OSM planet dump via 'osm2pgsql', compiling this into FlightGear Scenery > and to distribute the result under the GPL (as we've been doing for > ages). At least this is my understanding, therefore I still do sense > the need for clarification. > > Cheers, >Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -- > > > -- > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
Mathias Fröhlich wrote: > Hi all, > > For ac models, we have currently a step in the scenery loading process that > modifies the material settings to match the material settings of the old plib > loader. > In fact this just overwrites the material settings and throws away useful > information that is in the ac file that is still there up to the point where > we > just destroy that information. > I introduced that step at the time of the openscenegraph switch to make the > transition easier. > > I would like to remove that step now and make use of the full material > information contained in the ac file. > I believe that this is a step into the right direction, but this *does* > change > the visual appearance of some of our models. So when this gets removed, I > guess that some of the models material colours need to be adjusted in some > way. > > Comments? I'm working on something that might completely ignore the material settings in the .ac file, but I think that's OK. I'm adding support for effects files that specify, in addition to the material and parameter properties we have now in the .ac file, shaders, uniform parameters for the shaders, fallbacks for environments that don't have shaders. So far I've been working with the terrain, but my idea for models is to associate an effect with a material in the .ac file by using the material's name. There will more to comment on when I check in the first effects stuff later this week. Tim -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] .."./maketg NOPAUSE DOUPD" finds missing separator in gpc Makefile
Hi Geoff, ..I found a new bug with your maketg-1.0.3: 2009-03-16 22:02:57 (101 KB/s) - `gpc232.zip' saved [15606] Archive: gpc232.zip inflating: gpc232/gpc.c inflating: gpc232/gpc.h inflating: gpc232/VERSIONS.TXT making and installing gpc library... 47c47 < #define GPC_EPSILON (DBL_EPSILON) --- > #define GPC_EPSILON (0.01) If the above substitution of 0.1 for DBL_EPSILON looks correct, continue? Creating gpc makefile... # Unix/Linux makefile for GPC 2.32 # # Riley Rainey (riley.rai...@websimulations.com) \nCFLAGS = -O -g libgenpolyclip.a: gpc.o \trm -f $@ \tar cr $@ $< \tranlib $@ clean: \trm -f libgenpolyclip.a *.o core *~ install: libgenpolyclip.a \t-mkdir -p /usr/local/lib \t-mkdir -p /usr/local/include \tinstall libgenpolyclip.a /usr/local/lib/libgenpolyclip.a \tinstall gpc.h /usr/local/include/gpc.h \nCreated Makefile. Proceed to do make? Makefile:6: *** missing separator. Stop. a...@a45:/opt/bygg/tg $ -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nimitz elevators non solid
Mathias Fröhlich wrote : > Hi, > > On Thursday 12 March 2009 22:43:15 jean pellotier wrote: > >> I've got a problem with the elevators on nimitz, since some days, when >> called up, it looks ok, but elevator 3d model isn't solid, the part >> solid is where is the elevator down. >> each try i finish on the low position (in best case) under the elevator >> 3d model. >> > Ok, I have now checked in everything that I have in this area. > So, at least all *known* issues are solved. > Is that still a problem? > > Greetings > > Mathias > > work well now, thanks jano -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
Curtis Olson wrote: > [] I think the more of these material settings we can support so > that the model in the simulation looks just like the model in the 3d > modeling tool, the better life will be. Indeed, this will also pave the way for interchangeability between the various OSG-supported formats. Certainly a good move - which leaves the orientation of AC3D models as a remaining issue Now, we already have approx. 1k5 3D Scenery models, so chances are high that quite a few are affected by such a change and I'd be happy to apply an automated conversion if this is technically possible. What are we going to do about the users of our Scenery. Should we: a) leave the Scenery 3D models unchanged until the next software release, thus leaving users of FlightGear/CVS with strange-looking 3D models; b) convert the Scenery 3D models _now_ together with the software at the risk of unsatisfied users of the latest official software release; c) sync this sort of major changes with a minor software release ? My vote goes to c). Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] .."./maketg NOPAUSE DOUPD" FG compile error: simgear/scene/bvh/BVHNode.hxx: No such file or directory
On Mon, 16 Mar 2009 17:26:55 +0100, Geoff wrote in message
<1237220815.6654.5.ca...@dell02>:
> Hi Arnt,
>
> Without reviewing the maketg logs of the form templogNN.txt,
..doh! You still want my 1.0.2 logs?
> written to, in your case, the '/opt/bygg/fg/tmp/' (I think),
..correct, and I have /opt/bygg/tg/tmp/ for TG too if you want
them, /opt is my old 320GB (too small) Debian mirror disk. ;o)
> can only guess a little... but think I found it...
>
> >> undefined reference to `clock_gettime'
> =
>
> This is something Mathias added _VERY_ recently to SG/FG
> cvs - few days ago - see cvs logs...
>
> Either my maketg incorrectly downloaded/updated SG
> cvs, instead of git SG, which would be shown in the
> log files... or something else... checking further...
>
> >> error: simgear/scene/bvh/BVHNode.hxx: No such file or directory
> ==
>
> This seems to confirm wrong simgear is being used,
..maybe, I do have simgear-cs/simgear/scene/:
a...@a45:/opt/bygg/fg $ cd -
/opt/bygg/tg
a...@a45:/opt/bygg/tg $ ll simgear-cs/simgear/scene/
total 56
-rw-r--r-- 1 arnt arnt 15030 Mar 16 15:54 Makefile
-rw-r--r-- 1 arnt arnt 199 Mar 16 00:01 Makefile.am
-rw-r--r-- 1 arnt arnt 14567 Mar 16 15:54 Makefile.in
drwxr-xr-x 3 arnt arnt 4096 Mar 16 15:55 material
drwxr-xr-x 3 arnt arnt 4096 Mar 16 15:56 model
drwxr-xr-x 3 arnt arnt 4096 Mar 16 15:57 sky
drwxr-xr-x 3 arnt arnt 4096 Mar 16 15:58 tgdb
drwxr-xr-x 3 arnt arnt 4096 Mar 16 15:58 util
a...@a45:/opt/bygg/tg $ ll -d simgear-cs/simgear/scene/
drwxr-xr-x 7 arnt arnt 4096 Mar 16 15:54 simgear-cs/simgear/scene/
a...@a45:/opt/bygg/tg $
> since the last time I checked this whole directory
> simgear/scene/bvh
> has _NOT_ yet made it into the git repository... And my clone of
> simgear-cs just now confirms this...
>
> So it seems UNTIL this 'bvh' addition, and maybe other things,
> are added to the git repositories -
> - cvs FG will only compile with cvs SG
> - git TG will only compile with git SG
> - and cvs TG will NOT compile at all ;=(( unless perhaps
> a PRE-OSG SG, or at least an earlier version SG is used...
>
> And another 'clue' that somehow simgear(cvs) and
> simgear-cs(git) are confused...
> "-I/opt/bygg/fg/install/simgear/include"
> IFF you are doing TERRAGEAR then I think this should be
> "-I/opt/bygg/fg/install/simgear-cs/include"... hmmm
>
> AHH HA! GOT IT ;=)) My ~fg/maketg DOUPD NOPAUSE
> just ended with the similar error... WAIT, it is
> trying to compile FlightGear (FG) AND IT SHOULD NOT.
>
> As the above implies, cvs FG CAN NOT BE COMPILED
> AGAINST git SG!!! And maketg should NOT be compiling FG!
>
> Ok, looks like I got one of my && || chains in a twist ;=()
>
> Now fixed - try version 1.0.3
> http://geoffair.net/tmp/maketg
> http://geoffair.net/tmp/makefg
..got them.
> Hint: DOUPD redoes everything, thus takes big time. In
> your case you could now just run -
> /opt/bygg/fg$ maketg SGUPD TGUPD
> to skip tools, PLIB and OSG - OSG updates takes FOREVER ;=((
..ah. ;o)
> You will also _NOTE_ I left out the NOPAUSE, since after
> the TG git source clone/update you have to exit to _PATCH_
> terragear-cs/configure.ac ;=()
..I'll try maketg both ways to try learn something from
_how_ it crashes. ;o)
> No doubt you read my plea to add this to the TG git
> repository ... the patch is again included below -
>
> Without this PATCH applied to terragear-cs/configure.ac
> you can _NOT_ use --with-plib and --with-osg, and even the
> --with-simgear gets clobbered...
>
> With this new maketg 1.0.3, my update, patch, then continue
> build worked fine...
>
> And remember the script 'installs' the final TG executables
> in $HOME/bin,
..sure? And not /opt/bygg/tg/install nor
/opt/bygg/tg/install/bin in my case???:
a...@a45:/opt/bygg/tg $ ll $HOME/bin
ls: cannot access /home/arnt/bin: No such file or directory
a...@a45:/opt/bygg/tg $
> which I include in my path through an entry
> in .bash_aliases -
> export PATH=${PATH}:$HOME/bin
> You MUST change the script if you want them installed
> elsewhere...
..ok, for my 2 (fg & tg) trees, I will need
"export PATH=${PATH}:/opt/bygg/fg/install/bin" and
"export PATH=${PATH}:/opt/bygg/tg/install/bin" ?
..later, maybe make and install .deb's, .rpm's etc packages?
> Happy TG building...
>
> >> apt-cache show distcc ccache ccontrol dmucs
> ==
>
> Do not understand your point about these???
..I have a _pile_ of nice dumpster find boxes that can
run as distcc nodes ;o), half a dozen each of 1-3GHz
32bit P4, K7, 450-550MHz K6-2's, a dozen P3's, 3 64bit
P4's and a trashed amd64 laptop and they can double
as heat source, in the summer I can net boot them on
compile (farm) jobs. ;o)
> distcc - distributed compiler client and server
> ccache - Compiler results cacher
..this should work for your single box scenario too, caching old
compiled bits a
Re: [Flightgear-devel] [RFC] ac3d and materials
On Mon, Mar 16, 2009 at 2:16 PM, syd adams wrote: > Im also in favor of this change > I prefer to control the ambient property , myself. Let me also chip in that in a past simulation system I worked with, it was always highly annoying when a model looked good in the 3d modeler tool, but looked awful or just different once it was loaded up in the real time simulation. I think the more of these material settings we can support so that the model in the simulation looks just like the model in the 3d modeling tool, the better life will be. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
Im also in favor of this change I prefer to control the ambient property , myself. Cheers -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
On Mon, Mar 16, 2009 at 11:48 AM, Ron Jensen wrote: > Shouldn't ambient color be set scene wide? From an artistic point of > view I can see setting it on a per-material basis, but for a simulation > environment that controls the direct lighting already it makes sense to > give the ambient color over to the environment. Actually no. For each surface there are ambient, diffuse, specular, and emissive properties. These define the surface properties. For each light souce there are also ambient, diffuse, specular, and and emissive components. This defines the nature of the light that is cast on the surface. OpenGL combines the light source properties and the surface material properties to produce the actual visible color of the surface that is reflected back to the viewer. So it is correct to define the ambient, diffuse, specular, and emissive properties of the model surfaces. The environment defines the corresponding values for the light that illuminates the surface. OpenGl computes the correct color that is reflected back for each pixel. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] .."./maketg NOPAUSE DOUPD" FG compile error: simgear/scene/bvh/BVHNode.hxx: No such file or directory
Hi Arnt,
Without reviewing the maketg logs of the form templogNN.txt,
written to, in your case, the '/opt/bygg/fg/tmp/' (I think),
can only guess a little... but think I found it...
>> undefined reference to `clock_gettime'
=
This is something Mathias added _VERY_ recently to SG/FG
cvs - few days ago - see cvs logs...
Either my maketg incorrectly downloaded/updated SG
cvs, instead of git SG, which would be shown in the
log files... or something else... checking further...
>> error: simgear/scene/bvh/BVHNode.hxx: No such file or directory
==
This seems to confirm wrong simgear is being used,
since the last time I checked this whole directory
simgear/scene/bvh
has _NOT_ yet made it into the git repository... And my clone of
simgear-cs just now confirms this...
So it seems UNTIL this 'bvh' addition, and maybe other things,
are added to the git repositories -
- cvs FG will only compile with cvs SG
- git TG will only compile with git SG
- and cvs TG will NOT compile at all ;=(( unless perhaps
a PRE-OSG SG, or at least an earlier version SG is used...
And another 'clue' that somehow simgear(cvs) and
simgear-cs(git) are confused...
"-I/opt/bygg/fg/install/simgear/include"
IFF you are doing TERRAGEAR then I think this should be
"-I/opt/bygg/fg/install/simgear-cs/include"... hmmm
AHH HA! GOT IT ;=)) My ~fg/maketg DOUPD NOPAUSE
just ended with the similar error... WAIT, it is
trying to compile FlightGear (FG) AND IT SHOULD NOT.
As the above implies, cvs FG CAN NOT BE COMPILED
AGAINST git SG!!! And maketg should NOT be compiling FG!
Ok, looks like I got one of my && || chains in a twist ;=()
Now fixed - try version 1.0.3
http://geoffair.net/tmp/maketg
http://geoffair.net/tmp/makefg
Hint: DOUPD redoes everything, thus takes big time. In
your case you could now just run -
/opt/bygg/fg$ maketg SGUPD TGUPD
to skip tools, PLIB and OSG - OSG updates takes FOREVER ;=((
You will also _NOTE_ I left out the NOPAUSE, since after
the TG git source clone/update you have to exit to _PATCH_
terragear-cs/configure.ac ;=()
No doubt you read my plea to add this to the TG git
repository ... the patch is again included below -
Without this PATCH applied to terragear-cs/configure.ac
you can _NOT_ use --with-plib and --with-osg, and even the
--with-simgear gets clobbered...
With this new maketg 1.0.3, my update, patch, then continue
build worked fine...
And remember the script 'installs' the final TG executables
in $HOME/bin, which I include in my path through an entry
in .bash_aliases -
export PATH=${PATH}:$HOME/bin
You MUST change the script if you want them installed
elsewhere...
Happy TG building...
>> apt-cache show distcc ccache ccontrol dmucs
==
Do not understand your point about these???
distcc - distributed compiler client and server
ccache - Compiler results cacher
ccontrol - takes over roles of compiler, linker and make
dmucs - do not have it installed... seems part of distcc
I am happy compiling it all in one machine, without
'distributing' it over a network... but as I say do
not understand the real point here???
Anyway, thanks for pointing out the error in the scripts.
I will take more care with if ( a && b || c ) chains. I wanted
if ( a && ( b || c ) ), but got if ( ( a && b ) || c )... maybe
I should read up on the precedence and order in scripts ;=))
Regards,
Geoff.
--- tg-cs/terragear-cs/configure.ac 2009-03-14 18:36:33.0 +0100
+++ fg/terragear-cs/configure.ac 2009-02-12 17:35:34.0 +0100
@@ -26,6 +26,22 @@
EXTRA_DIRS="${EXTRA_DIRS} $with_simgear"
fi
+# specify the plib location
+AC_ARG_WITH(plib, [ --with-plib=PREFIX Specify the prefix path to
plib])
+
+if test "x$with_plib" != "x" ; then
+echo "plib prefix is $with_plib"
+EXTRA_DIRS="${EXTRA_DIRS} $with_plib"
+fi
+
+# specify the osg location
+AC_ARG_WITH(osg, [ --with-osg=PREFIX Specify the prefix path to
osg])
+
+if test "x$with_osg" != "x" ; then
+echo "osg prefix is $with_osg"
+EXTRA_DIRS="${EXTRA_DIRS} $with_osg"
+fi
+
dnl set the $host variable based on local machine/os
AC_CANONICAL_HOST
@@ -142,7 +158,8 @@
AC_CHECK_HEADER(windows.h)
dnl extra library and include directories
-EXTRA_DIRS="/usr/local/plib /usr/X11R6"
+# EXTRA_DIRS="/usr/local/plib /usr/X11R6"
+EXTRA_DIRS="$EXTRA_DIRS /usr/X11R6"
if test -d /opt/X11R6 ; then
EXTRA_DIRS="$EXTRA_DIRS /opt/X11R6"
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Re: [Flightgear-devel] [RFC] ac3d and materials
* Ron Jensen -- Monday 16 March 2009: > Shouldn't ambient color be set scene wide? From an artistic point of > view I can see setting it on a per-material basis, but for a simulation > environment that controls the direct lighting already it makes sense to > give the ambient color over to the environment. Hmm, maybe. But if you run the bo105 and use the Ctrl-y dialog, then you see what effects the various sliders have. And while some of them look just ugly and unrealistic, others don't. People who don't want separate control over diffuse and ambient can still just use the same values for both. But there's no reason to artificially limit possibilities IMHO. And in the end, different ambient and diffuse is what people will see in the AC3D editor. Breaking that appearance in fgfs is hard to justify. m. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
* Mathias Fröhlich -- Monday 16 March 2009: > The ambient part (amb in the ac file) in the ac files is just > ignored and set to the diffuse (rgb in the ac file) color part > by the post processing step. Thanks. So getting the old result is beyond trivial. Then there's IMHO no reason to delay this step. Taking the settings in *.ac files seriously is the right thing to do. Ignoring parts of them was acceptable for the transition phase, but in the long term it's just a bug. For me that's a clear "please go ahead"! (If someome doesn't want to bother fixing his/her aircraft: Just tell me and I'll make amb=rgb for them. Or rather, as script will do that. :-) m. PS: Thanks for all your recent work on fgfs. To me none of that looks like a fun job, but people are already noticing the big improvements. Sometimes I wonder what frame rates we would have today without your contributions, and my guess is 50%. It started with your rewriting/overhauling of plib's ac3d loader, then osg's ac3d loader, and ... -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
On Mon, 2009-03-16 at 16:50 +0100, Mathias Fröhlich wrote: > Hi, > > On Monday 16 March 2009 12:22:31 Melchior FRANZ wrote: > > Gets my vote! Which elements of the MATERIAL entry are thrown away > > at the moment, or which adjustments do people have to be prepared > > for? > > The ambient part (amb in the ac file) in the ac files is just ignored and set > to > the diffuse (rgb in the ac file) color part by the post processing step. > > So, all models with a different ambient color than the diffuse color will > look > different. It appears to me that some models have a very dark ambient color > and > this appear very dark on that side that points away from the sun. > > Greetings > > Mathias Shouldn't ambient color be set scene wide? From an artistic point of view I can see setting it on a per-material basis, but for a simulation environment that controls the direct lighting already it makes sense to give the ambient color over to the environment. My two cents, Thanks, Ron -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
Hi, On Monday 16 March 2009 12:22:31 Melchior FRANZ wrote: > Gets my vote! Which elements of the MATERIAL entry are thrown away > at the moment, or which adjustments do people have to be prepared > for? The ambient part (amb in the ac file) in the ac files is just ignored and set to the diffuse (rgb in the ac file) color part by the post processing step. So, all models with a different ambient color than the diffuse color will look different. It appears to me that some models have a very dark ambient color and this appear very dark on that side that points away from the sun. Greetings Mathias -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
Hi, On Monday 16 March 2009 11:31:08 Heiko Schulz wrote: > it depends on how many models are currently involved in these changes and > what are the advantages? I do not know which models are affected. And this is not easy to say. As some of the models just look different but not worse. Some of the models are just way too dark. The advantage is that you have more control over the material property of your surfaces. My personal impression with that change here in my local tree is that the models look better when they move - even if some colors look too dark at the first time. The surfaces behave more natural when the light direction changes. Well this is clearly my personal impression. The ac3d format has all 4 fields for the OpenGL material definitions. As far as I remember this post processing step ignores the ambient color and sets that equal to the diffuse one - or the other way round. ... may be I need to dig into that. I had at some time a sed script that just modified the material definitions the same way the post processing step did. But that is questionable too. Greetings Mathias -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nimitz elevators non solid
On lundi 16 mars 2009, Mathias Fröhlich wrote: > Hi, > > On Thursday 12 March 2009 22:43:15 jean pellotier wrote: > > I've got a problem with the elevators on nimitz, since some days, when > > called up, it looks ok, but elevator 3d model isn't solid, the part > > solid is where is the elevator down. > > each try i finish on the low position (in best case) under the elevator > > 3d model. > > Ok, I have now checked in everything that I have in this area. > So, at least all *known* issues are solved. > Is that still a problem? > > Greetings > > Mathias > AND now, again, working with poly ( face) not triangulated. Thanks for the work Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
On lundi 16 mars 2009, gerard robin wrote: > On lundi 16 mars 2009, Mathias Fröhlich wrote: > > Hi all, > > > > For ac models, we have currently a step in the scenery loading process > > that modifies the material settings to match the material settings of the > > old plib loader. > > In fact this just overwrites the material settings and throws away useful > > information that is in the ac file that is still there up to the point > > where we just destroy that information. > > I introduced that step at the time of the openscenegraph switch to make > > the transition easier. > > > > I would like to remove that step now and make use of the full material > > information contained in the ac file. > > I believe that this is a step into the right direction, but this *does* > > change the visual appearance of some of our models. So when this gets > > removed, I guess that some of the models material colours need to be > > adjusted in some way. > > > > Comments? > > > > Greetings > > > > Mathias > > AND now, again, working with poly ( face) not triangulated. > Thanks for the work > > Cheers Ouups sorry was the wrong topic -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
On lundi 16 mars 2009, Mathias Fröhlich wrote: > Hi all, > > For ac models, we have currently a step in the scenery loading process that > modifies the material settings to match the material settings of the old > plib loader. > In fact this just overwrites the material settings and throws away useful > information that is in the ac file that is still there up to the point > where we just destroy that information. > I introduced that step at the time of the openscenegraph switch to make the > transition easier. > > I would like to remove that step now and make use of the full material > information contained in the ac file. > I believe that this is a step into the right direction, but this *does* > change the visual appearance of some of our models. So when this gets > removed, I guess that some of the models material colours need to be > adjusted in some way. > > Comments? > > Greetings > > Mathias > AND now, again, working with poly ( face) not triangulated. Thanks for the work Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal animation
* itaf telecom -- Monday 16 March 2009: > I would like to know how to add an animation to an AI via nasal > I tried to load it from it's xml but it doesn't work. This would be easier to answer if you explained more about what exactly you are trying. You can: - use XML embedded Nasal to add animations or to modify existing animation definitions. But this works at model load time only! (There's no example for this in CVS, AFAIK, but an analogue technique is used in some gui dialogs, where buttons are created dynamically at load time. (Search for "button-template" in $FG_ROOT/gui/dialogs/nasal-console.xml). I don't think that's what you are after. - use XML embedded Nasal to drive properties that are used in animations. Example: the hangar in KNUQ where mouse-clicking the big doors opens/closes them (Ctrl-c to highlight them): $FG_ROOT/Scenery/Objects/w130n30/w123n37/moffett_hangar1.xml - let the model manager load a model and modify its position, orientation, control surfaces etc. via nasal. Example: $FG_ROOT/Nasal/tanker.nas (in CVS since yesterday) More info after *you* gave move info. :-) m. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] nasal animation
hi I would like to know how to add an animation to an AI via nasal I tried to load it from it's xml but it doesn't work. thanks for your help -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
* Mathias Fröhlich -- Monday 16 March 2009: > In fact this just overwrites the material settings and throws away > useful information [...] > I would like to remove that step now and make use of the full material > information contained in the ac file. Gets my vote! Which elements of the MATERIAL entry are thrown away at the moment, or which adjustments do people have to be prepared for? m. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenStreetMap Open Database License
Jon Stockill wrote: > Tim Moore wrote: > >> Obviously you've been following this more closely than I, but doesn't the >> proposed license specifically allow the use of OSM data in applications >> like flight simulators, with a fairly liberal license? > > I originally added the use case - it's been tweaked slightly since then, > and is currently awaiting a response from the lawyer. Not really much > to do until that decision materialises. Well, neither the former nor the current wording of the "computer game" use case actually reflect the process of extracting road data from the OSM planet dump via 'osm2pgsql', compiling this into FlightGear Scenery and to distribute the result under the GPL (as we've been doing for ages). At least this is my understanding, therefore I still do sense the need for clarification. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
Hi, it depends on how many models are currently involved in these changes and what are the advantages? Hi all, For ac models, we have currently a step in the scenery loading process that modifies the material settings to match the material settings of the old plib loader. In fact this just overwrites the material settings and throws away useful information that is in the ac file that is still there up to the point where we just destroy that information. I introduced that step at the time of the openscenegraph switch to make the transition easier. I would like to remove that step now and make use of the full material information contained in the ac file. I believe that this is a step into the right direction, but this *does* change the visual appearance of some of our models. So when this gets removed, I guess that some of the models material colours need to be adjusted in some way. Comments? Greetings Mathias -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FLOATING POINT INTERRUPT (SIGFPE)
Hello there, Sorry to bother you with the rookie problems, but I didn't find anything on the Archive about that. My newly installed FlightGear crashes when I launch it, and send me in terminal the error in the object. It appears to happen when loading the sceneries to be more precise. I am running Fedora 9 and SDL as Glut Utility. Did anyone get this problem before ? Cheers, JB -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [RFC] ac3d and materials
Hi all, For ac models, we have currently a step in the scenery loading process that modifies the material settings to match the material settings of the old plib loader. In fact this just overwrites the material settings and throws away useful information that is in the ac file that is still there up to the point where we just destroy that information. I introduced that step at the time of the openscenegraph switch to make the transition easier. I would like to remove that step now and make use of the full material information contained in the ac file. I believe that this is a step into the right direction, but this *does* change the visual appearance of some of our models. So when this gets removed, I guess that some of the models material colours need to be adjusted in some way. Comments? Greetings Mathias -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenStreetMap Open Database License
Tim Moore wrote: > Obviously you've been following this more closely than I, but doesn't the > proposed license specifically allow the use of OSM data in applications > like flight simulators, with a fairly liberal license? I originally added the use case - it's been tweaked slightly since then, and is currently awaiting a response from the lawyer. Not really much to do until that decision materialises. Jon -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nimitz elevators non solid
Hi, On Thursday 12 March 2009 22:43:15 jean pellotier wrote: > I've got a problem with the elevators on nimitz, since some days, when > called up, it looks ok, but elevator 3d model isn't solid, the part > solid is where is the elevator down. > each try i finish on the low position (in best case) under the elevator > 3d model. Ok, I have now checked in everything that I have in this area. So, at least all *known* issues are solved. Is that still a problem? Greetings Mathias -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenStreetMap Open Database License
Martin Spott wrote: > Martin Spott wrote: > >> OSM are currently discussing a draft of their to be expected future >> license for their road database. If you're interesed in having OSM >> roads show up one day in some future releases of the FlightGear World >> Scenery, then feel free to reserve some time, start at: >> >> http://wiki.openstreetmap.org/wiki/Open_Database_License > > Until now I didn't notice any of those who feel like caring for > FlightGear's future actually getting involved into the process. > >>From my very personal perspective this is fine, BUT, we should be aware > of the fact that we probably don't get OSM roads into FlightGear > Scenery for free. > So, if people are looking forward into having FlightGear Scenery > releases basing upon OSM roads (one day), they should deal with the OSM > re-licensing process and raise their voices there. Obviously you've been following this more closely than I, but doesn't the proposed license specifically allow the use of OSM data in applications like flight simulators, with a fairly liberal license? Tim -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
