Re: [Flightgear-devel] OSX 10.5 compilation
Maybe another possibility is to hang in a second mac slave to built maclauncher/FlightGear against SDK 10.5 and target 10.5. I could spend one of my FGx slaves once for such, when it makes sense for the project to get 10.5 support on intel back. Or another possibility is I try to build the official maclauncher out of jenkins locally here with such a setting, and when it is working you can put that to a separate 10.5 download. I would offer this work when there is some request for this, but first ... I would try to get atlas support back for osx when possible. I'm not able to compile atlas and I guess this is a really hard one for all osx versions. I hope that my findings with this can help the official launcher. It was always included with former version when I'm not wrong, and FGx doesn't support atlas either these days, unfortunately. (Another minority probably, but for me personally atlas is still one of the best maps we have, even this is a very old and a bit outdated project). -Yves Am 19.02.2013 um 02:07 schrieb ys : > Hi Curt > > I would not recommend to get 10.5 support back with current official jenkins > build. AFAIK current mac build for 10.6/7/8 works very well, supporting 10.5 > would need heavy changes, or better, downgrading of slaves, and it is > definitely not worth to break things this way. I'm free to do such on a small > private CI, and I made a lot of noise about having 10.5 support back, but at > the end it's just weird and for a very small minority of fg users like me. > But it is documented, and everyone joining the adventure can do so ;-) > > -Yves > > > > > Am 18.02.2013 um 18:54 schrieb James Turner : > >> >> On 18 Feb 2013, at 17:08, Curtis Olson wrote: >> >>> I haven't been following this thread too closely, but is it possible to get >>> 10.5 support back into the official build on Jenkins or does it require a >>> separate build/installer for 10.5 support? >>> >> >> I think the answer is no, since the build slave runs 10.6. >> >> If someone else disagrees, then I need to proceed carefully, since >> rebuilding the slave if we screw something up is not fun. (I could image the >> drive, I guess) >> >> James >> -- >> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, >> is your hub for all things parallel software development, from weekly >> thought >> leadership blogs to news, videos, case studies, tutorials, tech docs, >> whitepapers, evaluation guides, and opinion stories. Check out the most >> recent posts - join the conversation now. http://goparallel.sourceforge.net/ >> ___ >> Flightgear-devel mailing list >> Flightgear-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- > The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, > is your hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials, tech docs, > whitepapers, evaluation guides, and opinion stories. Check out the most > recent posts - join the conversation now. http://goparallel.sourceforge.net/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSX 10.5 compilation
Hi Curt I would not recommend to get 10.5 support back with current official jenkins build. AFAIK current mac build for 10.6/7/8 works very well, supporting 10.5 would need heavy changes, or better, downgrading of slaves, and it is definitely not worth to break things this way. I'm free to do such on a small private CI, and I made a lot of noise about having 10.5 support back, but at the end it's just weird and for a very small minority of fg users like me. But it is documented, and everyone joining the adventure can do so ;-) -Yves Am 18.02.2013 um 18:54 schrieb James Turner : > > On 18 Feb 2013, at 17:08, Curtis Olson wrote: > >> I haven't been following this thread too closely, but is it possible to get >> 10.5 support back into the official build on Jenkins or does it require a >> separate build/installer for 10.5 support? >> > > I think the answer is no, since the build slave runs 10.6. > > If someone else disagrees, then I need to proceed carefully, since rebuilding > the slave if we screw something up is not fun. (I could image the drive, I > guess) > > James > -- > The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, > is your hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials, tech docs, > whitepapers, evaluation guides, and opinion stories. Check out the most > recent posts - join the conversation now. http://goparallel.sourceforge.net/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSX 10.5 compilation
O, happy now. Finally it is working. And 2.10 is really a hit, compiled against sdk 10.5. One can still use an older macbook for simple multi-machine fun, with an old osx with bad bad graphics (old ATI, almost no vram). Now turning on 3d clouds, water, crop and transistion shader ... everything looks fine with a reasonable framerate (around 20fps). Only atmospheric lights, urban shader, random buildings/vegetation and some AI traffic reduces framerate to a no go. But really, well done, thanks guys. And special thanks to James and others nuking alut and making building sg/fg on a mac easier and easier (beside of my sound and boost troubles the last days, but that's just a private 2.10/osx learning curve here, I see). I am happy for the rest of the week (and shut up) because I got 2.10 working now from OSX 10.5 to 8, with simply downgrading boost and nuking macports. I will publish a version with FGx asap. Now I see that the small cocoa change for flightgear making compiling possible for 10.5 has already been merged by James, thanks, the patch for the simgear sdk 10.5 svn problem will follow asap. Thanks, Yves Am 18.02.2013 um 14:41 schrieb ys : > Hi James > > Have some news, I got sound back with simgear/sound/openal_tests, compiled > against sdk 10.6. Now I'm going to make some other tests with fg vs. 10.5. > What I changed in my chain is nuking macports boost 1.52 and bringing back > 1.50 with a manual install on the slave. > > I've seen that your jenkins slave uses 1.52. Maybe this works well with > devtools >= 4, here I'm using 3.2.6 for the slave to get sdk 10.5. Is there a > reason to install boost 1.52, or is 1.50 ok for the next days ? ;-) And > another question, do you remember what options you used for installing boost > 1.52 on the slave ? > > Thanks, Yves > > > > Am 18.02.2013 um 03:01 schrieb ys : > >> >> >> >> >> >> Am 16.02.2013 um 00:56 schrieb ys : >> >>> so I really have no idea what might be going. >> >> Hi James >> >> Me too. But it is still here. SimGear throws the same issue with all >> combinations I tried, and now after goinf for 2.10 also with SDK 10.6. >> Meantime I guess it is more a general problem, I don't know what the >> wavreader throws when the path is wrong to the wav file i.e. Because in the >> error message I don't see any path, and when I'm looking to the wavreader >> code it should throw the path, or not ? So next question is does the >> wavreader throw "truncated or corrupt" when it doesn't find the .wav file ? >> I edited the simgear code and realised that what I see in fg log is the >> first exception that can be thrown with message "truncate/corrupt". >> >> Any other ideas what I should take into account ? >> >> -Yves >> -- >> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, >> is your hub for all things parallel software development, from weekly >> thought >> leadership blogs to news, videos, case studies, tutorials, tech docs, >> whitepapers, evaluation guides, and opinion stories. Check out the most >> recent posts - join the conversation now. http://goparallel.sourceforge.net/ >> ___ >> Flightgear-devel mailing list >> Flightgear-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- > The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, > is your hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials, tech docs, > whitepapers, evaluation guides, and opinion stories. Check out the most > recent posts - join the conversation now. http://goparallel.sourceforge.net/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSX 10.5 compilation
Hi James Have some news, I got sound back with simgear/sound/openal_tests, compiled against sdk 10.6. Now I'm going to make some other tests with fg vs. 10.5. What I changed in my chain is nuking macports boost 1.52 and bringing back 1.50 with a manual install on the slave. I've seen that your jenkins slave uses 1.52. Maybe this works well with devtools >= 4, here I'm using 3.2.6 for the slave to get sdk 10.5. Is there a reason to install boost 1.52, or is 1.50 ok for the next days ? ;-) And another question, do you remember what options you used for installing boost 1.52 on the slave ? Thanks, Yves Am 18.02.2013 um 03:01 schrieb ys : > > > > > > Am 16.02.2013 um 00:56 schrieb ys : > >> so I really have no idea what might be going. > > Hi James > > Me too. But it is still here. SimGear throws the same issue with all > combinations I tried, and now after goinf for 2.10 also with SDK 10.6. > Meantime I guess it is more a general problem, I don't know what the > wavreader throws when the path is wrong to the wav file i.e. Because in the > error message I don't see any path, and when I'm looking to the wavreader > code it should throw the path, or not ? So next question is does the > wavreader throw "truncated or corrupt" when it doesn't find the .wav file ? I > edited the simgear code and realised that what I see in fg log is the first > exception that can be thrown with message "truncate/corrupt". > > Any other ideas what I should take into account ? > > -Yves > -- > The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, > is your hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials, tech docs, > whitepapers, evaluation guides, and opinion stories. Check out the most > recent posts - join the conversation now. http://goparallel.sourceforge.net/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSX 10.5 compilation
Am 16.02.2013 um 00:56 schrieb ys : > so I really have no idea what might be going. Hi James Me too. But it is still here. SimGear throws the same issue with all combinations I tried, and now after goinf for 2.10 also with SDK 10.6. Meantime I guess it is more a general problem, I don't know what the wavreader throws when the path is wrong to the wav file i.e. Because in the error message I don't see any path, and when I'm looking to the wavreader code it should throw the path, or not ? So next question is does the wavreader throw "truncated or corrupt" when it doesn't find the .wav file ? I edited the simgear code and realised that what I see in fg log is the first exception that can be thrown with message "truncate/corrupt". Any other ideas what I should take into account ? -Yves -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSX 10.5 compilation
Hi all Ok, can we have a decision that SimGear/FlightGear is not supporting OSX 10.5 on intel anymore ? FG 2.8 is doable, and maybe 2.10 with some further tweaks too, but after looking to what's coming up with "next" I see that more and more tweaks are needed and that core developers do not take 10.5 into account anymore (what I can understand very well, but it's not mentioned anywhere, when I'm not wrong). Fact is that all dependencies still supports osx 10.5 on intel, but sg/fg doesn't anymore (since 2.8 this is also posted at flightgear.org for mac release, >= 10.6). As stated by James sg/fg code is not tested against 10.5 by core developers anymore, so please ... I my view a small message should come to changelog which can be referenced by "supporters" at forums and elsewhere for this fact. Or do you think this is completely wrong ? -Yves Am 13.02.2013 um 22:19 schrieb ys : > Hi James > > Thanks a lot for all your replies, gave me some hope ;-) But I guess I'm not > able to make FGx possible for mac users with built-in osg/sg/fg the next > days, because of this strange sound problem. Ok, this doesn't matter that > much, because FGx is only a very small side project and an unofficial "fg > side release", even when I tried to follow the official release plan with > this piece the last months. Maybe it's a simple slave hardware issue, or > there is some strange behaviour with the macports setup and I need to hang > another machine with a fresh new install into jenkins. As the official mac > release has working sound I guess it's really not related to sg/fg code at > all, sorry for the noise. And as a launcher without built-in libs FGx still > works on macs, also with 2.10. > > All these things need a lot of time, and many thanks for your support and > thoughts. When I installed a jenkins some months ago I thought we can switch > version with the new build, skipping a dependency here and there, and build > it, release, finish, without a lot of tweaks. Forget that with flightgear > (and Yves, and osx, and all this old unused machines) ;-) My last hope is now > that I can bring back some findings that are useful for others the next days > probably, and that I get a new build that makes FGx 2.10 also possible for > mac users. It's not impossible, but I still have no idea why the sound has > gone. > > -Yves > > > > > Am 13.02.2013 um 11:39 schrieb James Turner : > >> >> On 13 Feb 2013, at 10:05, ys wrote: >> >>> Are you using a flag on jenkins shell or rb script I couldn't see and I >>> need to take into account? should I try on another machine first ... Or is >>> there some mystic endianess I should take into account for this first >>> generation intel macs? I wonder that I had absolutely no problems with alut >>> and 2.8 some months ago. >> >> If you're on Intel, and the 2.10 official release works, I am stumped. The >> code is /extremely/ simple - open file, read some bytes. There's no scripts >> or options or anything to control it, as far as I know. >> >> And there's no mystic endian-ness, and plenty of people on Linux use 32-bit >> builds - so I really have no idea what might be going. >> >> Sorry, not helpful I realise. >> >> James >> >> -- >> Free Next-Gen Firewall Hardware Offer >> Buy your Sophos next-gen firewall before the end March 2013 >> and get the hardware for free! Learn more. >> http://p.sf.net/sfu/sophos-d2d-feb >> ___ >> Flightgear-devel mailing list >> Flightgear-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release 2.10.0: Decision Altitude
Hi Torsten What does mean "no public answer" in this list for this decision ? -Yves Am 15.02.2013 um 16:16 schrieb Torsten Dreyer : > Hi all, > > at one point during every ILS approach you reach the decision altitude > with two options: "continue approach" or "go around". Being the copilot > on our approach into the 2.10 release, I'd call out "minimum, approach > lights in sight, continue!" > > If no one shouts out loudly _NOW_, I'm going to tag the release branches > tomorrow (Saturday) morning (Central European Time) and give the package > managers the GO to build and distribute the bundles. That should give us > a ready-to-download release just in time on Sunday the 17th. > > Greetings, > Torsten > > -- > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake question simgear include option
Hi James Thanks, yes, am aware of this kind of separation. But I thought: "Why does cmake configuration make it possible to link against an osg include and lib dir for every part, while simgear has only a an option for headers and not the libs ?". And then when you set the simgear include dir, why does simgear link against system path libs and not against cmake install prefix? What speaks against linking the libs? Or what speaks against keeping this simgear include option away? I don't get the logic behind this, and of course me I do not run into real problems because of this, I am just a bit curious about what's behind this option setting. -Yves Am 15.02.2013 um 09:48 schrieb James Turner : > > On 14 Feb 2013, at 18:58, HB-GRAL wrote: > >> With simple -DCMAKE_INSTALL_PREFIX it finds the "custom location" of the >> headers and libs without any other option, but when I add >> -DSIMGEAR_INCLUDE_DIR=/path/to/include it takes the headers from this >> location, but not the libs anymore, it falls back to another simgear >> install on my system (which is in path). So I need to remove default >> simgear from my path, and then cmake works perfect. >> >> Sometimes I wonder with what things I can struggle with flightgear >> compilation and why only ME have such problems. ;-) > > Avoid setting the include path directly, would be my advice. > > If you want to use different simgear builds, then keep the completely > separate. > > Eg, I have: > >~/FGFS/ >simgear >flightgear > >fgBuild# configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist >sgBuild# configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist >dist > >fgBuild2# configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist2 >sgBuilld2# configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist2 >dist2 > > And this works fine for me, the different diet trees can have totally > different version / config options since there is no overlap at all. > > James > -- > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSX 10.5 compilation
Hi James Thanks a lot for all your replies, gave me some hope ;-) But I guess I'm not able to make FGx possible for mac users with built-in osg/sg/fg the next days, because of this strange sound problem. Ok, this doesn't matter that much, because FGx is only a very small side project and an unofficial "fg side release", even when I tried to follow the official release plan with this piece the last months. Maybe it's a simple slave hardware issue, or there is some strange behaviour with the macports setup and I need to hang another machine with a fresh new install into jenkins. As the official mac release has working sound I guess it's really not related to sg/fg code at all, sorry for the noise. And as a launcher without built-in libs FGx still works on macs, also with 2.10. All these things need a lot of time, and many thanks for your support and thoughts. When I installed a jenkins some months ago I thought we can switch version with the new build, skipping a dependency here and there, and build it, release, finish, without a lot of tweaks. Forget that with flightgear (and Yves, and osx, and all this old unused machines) ;-) My last hope is now that I can bring back some findings that are useful for others the next days probably, and that I get a new build that makes FGx 2.10 also possible for mac users. It's not impossible, but I still have no idea why the sound has gone. -Yves Am 13.02.2013 um 11:39 schrieb James Turner : > > On 13 Feb 2013, at 10:05, ys wrote: > >> Are you using a flag on jenkins shell or rb script I couldn't see and I need >> to take into account? should I try on another machine first ... Or is there >> some mystic endianess I should take into account for this first generation >> intel macs? I wonder that I had absolutely no problems with alut and 2.8 >> some months ago. > > If you're on Intel, and the 2.10 official release works, I am stumped. The > code is /extremely/ simple - open file, read some bytes. There's no scripts > or options or anything to control it, as far as I know. > > And there's no mystic endian-ness, and plenty of people on Linux use 32-bit > builds - so I really have no idea what might be going. > > Sorry, not helpful I realise. > > James > > -- > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSX 10.5 compilation
Hi James I'm stuck with this now. And no, there is no arch PPC, I'm just compiling with i386 against SDK 10.5 and target 10.5 with arch i386 only, but also when I switch to 10.6 SDK and target 10.6 I get no wav sound and fg hangs. I opened the wavs with other software, no problem, I downloaded 2.10 release dmg and run it with 10.6 on this machine ... and get no sound problems?! I checked CMakeCache of simgear and flightgear on jenkins against my cache and could not find any important difference. The only thing different is that I use arch i386 explicitely and I set SDK and target with cmake. The log shows the same, sound is enabled ... I checked all the links of fgfs, exactly the same. I'm assuming that simpits mac is i386 too and is the same hardware generation more or less (but I'm not sure about). Are you using a flag on jenkins shell or rb script I couldn't see and I need to take into account? should I try on another machine first ... Or is there some mystic endianess I should take into account for this first generation intel macs? I wonder that I had absolutely no problems with alut and 2.8 some months ago. I could try to compile on another slave, a x86_64 machine and have a look what happens there, or I could edit the wavreader code to see more clearly where the problem occurs and if it's really the byte order (what I could not imagine, but one never knows). No other ideas at the moment. Arghh, maybe it's just a small little thiny bit I miss, a new simgear/flightgear build guru bity I don't get. Thanks, Yves Am 12.02.2013 um 15:23 schrieb James Turner : > > > On Feb 11, 2013, at 03:05 PM, ys wrote: > >> Hi James >> >> I guess this forking would be possible with the cocoa and the svn patch, but >> I'm struggling with something different at the moment. Everything compiles >> fine against 10.5 but when I start flightgear I have no engine sound, and >> when engine sounds are activated fg hangs (no segfault). I can only startup >> with aircrafts that have no engines running (i.e. c172p or b1900), the >> others will crash flightgear and I get a simgear log entry that the >> associated wav files are corrupted or truncated. Ehrm, looking where this >> message is generated there are a lot of possibilities in your new wavreader >> ;-) >> >> Can you give me any hint where this OpenAL sound problem could reside? >> Strange thing is that avionics sound works (i get some 'instrument beeps' in >> b1900 i.e.), only the engine is a problem. When I turn off sounds (switching >> off master in the GUI) everything works as expected, I get 30 fps without >> shaders and out of KSFO, keys are working etc. Maybe this is not related to >> 10.5 at all and there are some other important changes/patches for osx >> compilation I missed after alut nuke ? > > To be honest I have no ideas - the WAV reading code is extremely simple, and > copied directly from the ALUT sources - it's used everywhere - Windows, Linux > and Mac, with no #ifdefs. So I can't imagine why some sounds would work and > not others. Except, some of our beeps (morse code) are synthesised, not > loaded from WAVs. > > Some WAVs are stereo, but the code must handle this or every platform would > die. Could it be an endian issue? PPC? > > Ah, I wonder if I assumed PPC was gone, when porting the code? So you might > need to add byte-swapping into the code, if __PPC__ is set. > > James > -- > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSX 10.5 compilation
Hi James I guess this forking would be possible with the cocoa and the svn patch, but I'm struggling with something different at the moment. Everything compiles fine against 10.5 but when I start flightgear I have no engine sound, and when engine sounds are activated fg hangs (no segfault). I can only startup with aircrafts that have no engines running (i.e. c172p or b1900), the others will crash flightgear and I get a simgear log entry that the associated wav files are corrupted or truncated. Ehrm, looking where this message is generated there are a lot of possibilities in your new wavreader ;-) Can you give me any hint where this OpenAL sound problem could reside? Strange thing is that avionics sound works (i get some 'instrument beeps' in b1900 i.e.), only the engine is a problem. When I turn off sounds (switching off master in the GUI) everything works as expected, I get 30 fps without shaders and out of KSFO, keys are working etc. Maybe this is not related to 10.5 at all and there are some other important changes/patches for osx compilation I missed after alut nuke ? -Yves Am 10.02.2013 um 15:14 schrieb James Turner : > > On 10 Feb 2013, at 13:48, ys wrote: > >> So my goal is to have flightgear 2.10 still up for using on a second old >> intel machine in the network (no ppc, but where 10.5 install was the origin >> and therefor probably the fastest, 10.7 does not run on this machines and >> 10.6 is not a free update). I imagine a "low budget second or third >> instance" for some scenarios, still with reasonable framerate, but without >> all the sophisticated graphics, yes. >> >> I will send some merge requests, but it's up to you or others to decide if >> it is worth to have this directives in code, because it's not that longterm >> perspective probably and it's a bit crazy for well known reason to still >> support 10.5. > > If they are really intrusive we could make a fork from 2.10 to apply them, > and keep them out of next? > > But less see before we worry about that! > > James > > > -- > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSX 10.5 compilation
Hi James Sounds like paranoia on my side, about a "decision", sorry for that. But I feared that I missed some discussion about 10.5 and spend too much time on something that isn't a goal anymore .. So my goal is to have flightgear 2.10 still up for using on a second old intel machine in the network (no ppc, but where 10.5 install was the origin and therefor probably the fastest, 10.7 does not run on this machines and 10.6 is not a free update). I imagine a "low budget second or third instance" for some scenarios, still with reasonable framerate, but without all the sophisticated graphics, yes. I will send some merge requests, but it's up to you or others to decide if it is worth to have this directives in code, because it's not that longterm perspective probably and it's a bit crazy for well known reason to still support 10.5. Thanks, Yves Am 10.02.2013 um 12:56 schrieb James Turner : > > On 9 Feb 2013, at 20:49, ys wrote: > >> But with some small directives I tested today I see that it would be >> possible to still port fg 2.8 and 2.10 for osx sdk 10.5. I don't want to >> offend anyone for this >= 10.6 decision or the code, but please can you >> point me to some sources posts/threads/reports where I can see the reason >> for this decision and where the problems resides ? > > There's no decision, if you want to keep 10.5 support just send me patches or > submit merge requests, that's fine. > > Personally I have no way to test 10.5, and I don't really think there's many > 10.5 Macs which will run FGFS at a usable framerate, but I am happy to be > wrong about that! (On the basis that most people who can upgrad to 10.6 or > 10.7 would have done so, so it's mostly PPC Macs, which have Radeon-1 class > hardware) > > James > > > -- > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OSX 10.5 compilation
Hi all While there is absolutely no problem to compile OSG and other deps against osx sdk 10.5 there has been some bits introduced in simgear/flightgear now to not compile against sdk 10.5 anymore. The cocoa code I already mentioned requires only a small directive (sorry about the dyslexia in my patch, I just realized that things needs review ;-) ), but I see also some other code i.e. in simgear that doesn't take sdk 10.5 into account anymore (terrasync.cxx and svn version directives i.e.). My question is: Has there been a decision by the core team not to port SDK 10.5 anymore I missed ? When I look to official release announcements I see that Mac version supports >= 10.6 since 2.8 ... But with some small directives I tested today I see that it would be possible to still port fg 2.8 and 2.10 for osx sdk 10.5. I don't want to offend anyone for this >= 10.6 decision or the code, but please can you point me to some sources posts/threads/reports where I can see the reason for this decision and where the problems resides ? Thanks, Yves -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tooltips / usability
Hi James Maybe this leads here to extend the current liberation font set to provide some additional glyphs, i.e. "key pictures" etc. for tutorials or the tooltips bubbles, or some special "aviation glyphs"? And this for the sans and mono, and to get better readable screen fonts at all. Or is there a font already for such in the repo? I can do such work the next weeks when there is use on canvas, or does your effort still rely on plib/txf ? -Yves Am 09.02.2013 um 12:47 schrieb James Turner : > A wee heads-up, > > I'm working on tooltip support, since I think it could offer a huge usability > win. There's a couple of points here: > >- hovering over a pickable item can show a configurable prompt: think > 'Avionics Master: ON' or 'Fuel tank selector: LEFT TANK' > >- pickable controls, including the new knob animation, will be able to > show a floating bubble with the live value as they change. This should make > controls where the feedback value is not beside the knob/dial/lever much more > usable - e.g. the CRS / HDG knobs in the Citation-X, would show a tooltip > with 'Course - 129 deg' changing in realtime. Even for toggle switches, > often the legibility of the panel text isn't great, so a pop-up confirming > the new state should really help people, I think. > > (of course we can have a global pref to disable such tips for people who find > them distracting / unnecessary) > > But there's a final benefit - I can imagine tutorials using the same > mechanism to place a prompt text in world coordinates, i.e 'click this thing > here!'. Which would obviously be beneficial in many complex cockpits. That > will need a bit more work, of course. > > I'm expect a few iterations to find something that is usable without being > intrusive, so please be patient. In particular the interaction with the > existing (centred) 'popup text' mechanism needs to be figured out, to avoid > cluttering the screen. > > Regards, > James > > -- > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Synchronizing nav.dat ?
Hi Olivier I guess many parts of nav.dat updates are related to updates in apt.dat (i.e. ILS, VOR-DME freqs etc.). For me personally it only makes sense to update to current navaids when apt.dat can be updated too, otherwise I guess the project will get much more reports immediately than you actually see. Maybe it's better to update the whole xplane data at once with a new scenery release and have some kind of a new and in-sync "xplane data consistency" from this point ? -Yves Am 05.02.2013 um 21:00 schrieb Olivier : > Hi all, > Concerning the release process, is there any plan to synchronize our nav.dat > with XPlane's ? > There are a few bug reports and user reports noticing errors with NDBs > locations or VOR frequencies not updated, for instance. > Is there any possibility to update this? > Would there be any drawback or concern we would have to look after carefully? > Thanks for them, > Olivier > -- > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Small patch for cocoa 10.5 support
Hi
I know, it's annoying with 10.5, but I realised tonight that an older cocoa
pasteboard commit broke flightgear osx cocoa 10.5 support and I kindly ask you
to verify the patch below. With this code it is still possible to compile
flightgear with target 10.5 and sdk 10.5. I will use this for the FGx launcher
which still supports 10.5 (I hope), and as this is the only commit since some
months that breaks 10.5 support ... could this code go to flightgear repo,
unless flightgear osx 10.5 support is deprecated completely ?
Thanks, Yves
--- ClipboardCocoa.mm2013-02-03 23:17:09.0 +0100
+++ ClipboardCocoa.mm.patched2013-02-03 23:23:47.0 +0100
@@ -67,7 +67,11 @@
if( type == CLIPBOARD )
{
NSPasteboard* pboard = [NSPasteboard generalPasteboard];
+#if MAC_OS_X_VERSION_MIN_REQUIRED >= 1050
+NSString* nstext = [pboard stringForType:NSStringPboardType];
+#else // > 10.5
NSString* nstext = [pboard stringForType:NSPasteboardTypeString];
+#endif // MAC_OS_X_VERSION_MIN_REQUIRED
return stdStringFromCocoa(nstext);
}
@@ -85,8 +89,16 @@
{
NSPasteboard* pboard = [NSPasteboard generalPasteboard];
NSString* nstext = stdStringToCocoa(text);
-[pboard clearContents];
-[pboard setString:nstext forType:NSPasteboardTypeString];
+#if MAC_OS_X_VERSION_MIN_REQUIRED >= 1050
+NSString* type = NSStringPboardType;
+NSArray* types = [NSArray arrayWithObjects: type, nil];
+[pboard declareTypes:types owner:nil];
+[pboard setString:nstext forType: NSStringPboardType];
+#else // > 10.5
+NSString* type = NSPasteboardTypeString;
+[pboard clearContents];
+[pboard setString:nstext forType:NSPasteboardTypeString];
+#endif // MAC_OS_X_VERSION_MIN_REQUIRED
return true;
}
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CI server
Hi Gene Could have different reason, is also reported as bug with some jenkins versions ... https settings for anonymous user, windwos server, proxied and "wrong" proxy configuration ... In case you're running a nginx proxy I could send you another configuration to compare, with settings that work here for http and https. -Yves Am 21.01.2013 um 15:29 schrieb geneb : > On Sun, 20 Jan 2013, ys wrote: > >> Hi >> >> Sorry for that and I don't want to shout loud about anything (mostly), >> but after some months ... is it possible to get the images back somehow >> on the official CI server? I mean, with all respect for whatever >> console, but I need to note that this server is some kind of a "flag" >> for some less well-off developers and users probably too, and beside of >> that ... I stop know, but really, is it possible? At least during a >> pre-release and release cycle? ;-) > > I don't know what causes it. All I know is when you log in to the page, > the images re-appear. The odd thing is that the paths to the images never > changes between being logged in (shows images) and logged out (shows no > images). > > g. > > -- > Proud owner of F-15C 80-0007 > http://www.f15sim.com - The only one of its kind. > http://www.diy-cockpits.org/coll - Go Collimated or Go Home. > Some people collect things for a hobby. Geeks collect hobbies. > > ScarletDME - The red hot Data Management Environment > A Multi-Value database for the masses, not the classes. > http://www.scarletdme.org - Get it _today_! > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122412 > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bucket change
Hi Mathias Does this also solve the NSZP problem, the south-pole-crossing-runway-problem now? Good news ... A lot of contemporary geodesic software has problems with this, good to hear that flightgear is walking through the "last" two degrees. I do not ask how this is done, this is far from whatever I could understand with such. But great! Yves Am 20.01.2013 um 15:49 schrieb Mathias Fröhlich : > > Hi, > > like already negotiated with the scenery guys, I have now pushed a change to > the bucket tiling at the poles. The current scenery does not handle these > cases well anyway, the tiles there look very much broken. > So, there is not much lost in the current state by this change. > > The scenery guys promised me that the next scenery build is nearing, so the > hope is that they will pick up this change and we get by that a whole world > scenery without holes, even including the 2 degrees around the poles. > > In any case this is at the very beginning of the development cycle so that > problems arising from this change should have enough time to be iterated out > before the next release. > > Greetings > > Mathias > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_123012 > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] CI server
Hi Sorry for that and I don't want to shout loud about anything (mostly), but after some months ... is it possible to get the images back somehow on the official CI server? I mean, with all respect for whatever console, but I need to note that this server is some kind of a "flag" for some less well-off developers and users probably too, and beside of that ... I stop know, but really, is it possible? At least during a pre-release and release cycle? ;-) -Yves -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TrueType font editing
Hi James I guess there are a lot of SIL or other open source fonts out there which fit fg license and probably also your needs. You can choose one you prefer or which comes close to what you need, monospaced or not, and I can make the ttf for you, when it is not there already. I know this tools, can modify with special glyphs or whatever. Could take some time, nice editing of fonts is not a quick task. I would recommend to start with a open source font already there. Anyway a long time ago I proposed once in this list to replace the fonts used within flightgear with better and in open source license available fonts, like many other projects. Because this is my "business" I would really help to find the right fonts from a designers perspective. Cheers, Yves Am 12.01.2013 um 19:28 schrieb James Turner : > I'm having fun creating a CDU instrument using the canvas! > > But I've encountered an issue that is most easily be solved, by creating a > custom TrueType font - I want to replace the lowercase letters with 'small' > upper-case letters, but keep the fixed width of the larger size. (Anyone > who's played with a Honeywell / Smiths CDU can guess what I'm up to here….). > > There's a few other issues (relating to our lack of Unicode support) I could > also solve with some font hackery, especially some custom symbols. > > So - does anyone have any practical experience with manipulating TTF fonts? > Please don't reply with lists of the tools available - I've already found > those via Google - I'm wondering if anyone has any practical experience of > actually doing this! > > My starting point for now would be one of the fixed-width Liberation TTF > fonts checked into fgdata, so there's no licensing issue. In the distant > future I might consider finding a more CDU-alike font to edit, but I suspect > there won't be many with a compatible license. > > Regards, > James > > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122912 > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata Commit c8a69dffd49a298e01c0e0e1320f4a1d49a0bca4
Hi Clement Am 21.12.2012 um 09:40 schrieb Clement de l'Hamaide : > Hi Yves, > > > Maybe the PAF team has to take into account that Helijah spent half of his > > life contributing to flightgear models and this needs some personal respect > > and not only respecting gpl terms. [...] but to be honest, it has not the > > same history like the contribution of Emanuel > > Does it mean that in your opinion PAF team has no personal respect for > helijah ? Does it mean that helijah can legitimately insult and denigrate > other contributors/contributions ? No, absolutely not. Never, that would be a misinterpretation of my sentences. In my opinion the only possibility to prevent the project from such things for future ongoings is to split parts of fgdata, i.e. the aircraft directory into hangers, adding a proper history file to each aircraft which needs to be kept in directory when you fork (what's normal anyway I think?). Maybe this needs a period of "hanger" subscription where people can show their interests in binding/adding a hanger to the project and where current developers are asked to found a own hanger. I would also like to see a "wreckyard" where new developers can pick up some projects probably ;-) And maybe this needs an active fg hanger project site (or hanger section on current sites) where you get overview and can follow this change. I would help to write down history of lets say 10-15 aircraft, contact former and recent contributors, make a proposal for a readme and ask them where to put their work and document this ongoings on a "official site". It's a collaborative effort, it needs a plan, it needs a standard copyright and license notice which needs to be kept. My assumption is that it will take 6 months or more, but it is doable. I know 10 aircraft is not that much, but I would take responsability for this, that it goes to the right hanger for a new start of aircraft directories for fg, without loosing history, that this work is documented and former contributors know where their work has gone in case they do not found a own hanger. But at the end it is a decision of the core team if they give support for such a change or not, or if this remains a discussion of "who presents the most clever git commands" ;-) -Yves-- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata Commit c8a69dffd49a298e01c0e0e1320f4a1d49a0bca4
Hi Clement Yes it is really sad to see such commit messages. But maybe the PAF team also thinks too concurrently in headers, gpl and copyright notice and file descriptions here. Maybe the PAF team has to take into account that Helijah spent half of his life contributing to flightgear models and this needs some personal respect and not only respecting gpl terms. For me personally the contribution of the PAF is very welcome, but to be honest, it has not the same history like the contribution of Emanuel. Even when it sounds strange to you, try to talk to him directly. I guess no one here wants to judge about small coyright thinking and "who was first", "who violates gpl by gpl" and other childish games (which points mainly to Emanuel, who is responsible for many reallly bad commit messages, forum messages, in a really bad manner). But at the end here we are all volunteers, and the best you can do, the best the PAF team can do for the project is ... keep your work up, get commit rights and commit and try to communicate in a good way, a long time. Never blame others for doing this or that to make us judge about "who is right". Helijah does it the "hidden" way in his commit messages, everyone knows and ignores, but you do it here officially in the list. Don't think people here are so stupid that they do not realise what's going on. The Flightgear Project made the bad mistake to miss to split the code into "core" and "plug-ins" with fg/sg vs. parts of fgdata, making it possible to have "hangers" for example. Maybe the core devs will make a better decision about this once, or when the current core team realise what fgdata has become actually, or another core team. Lets say thanks to all fgdata contributors who makes not that much noise and are patient all the days, really. -Yves Am 20.12.2012 um 23:44 schrieb Clement de l'Hamaide : > <<[..] Not only do they believe to be the authors of this aircraft but they > also break existing things for the pleasure of breaking. >> > > It's sad to see this kind of commit description in a public place of the > FlightGear project. > > For information, the commit is about the improvement made by PAF team on the > DR400. (Of course nobody from PAF team asked him to push their work in the > repo. It's his own choice to download the work done by PAF team and use it > for it's own DR400) > As the GNU GPL licence says : it's highly recommended to add a copyright > header for each file created/modified. It's exactly what PAF team done adding > "Modified by PAF team" (in case of file modification) or "Created by PAF > team" (in case of file creation) as copyright header. Unfortunately helijah > has removed all these copyright header before pushing the work made by PAF > team on the repo. > > I can't imagine what would be the reaction of Curt if a commiter remove the > header copyright of the file flightgear/src/Main/main.cxx . The fault made by > helijah is the same here : he removed the copyright header (recommended by > GNU GPL licence) of files for the second time (the first one was : > https://gitorious.org/fg/fgdata/commit/7bc193ad0af206f166f2ab768880cec07891faa6 > ) > > I will skip all the insults publicly written by helijah for just focusing > your attention about the past and current licence / copyright violation > brought by this contributor (red bull livery (z-lin50), sound file(reported > by Pierre), texture file (JAS39-gripen). I think that a real solution has to > be discussed here in order to avoid any new problem with this contributor. > > Cheers, > Clément > -- > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on FG on Linux/Windows
Hi Curt Maybe these are two types of conferences now. One could be the WIFGH, the Weekly International FlightGear Hangout ;-) Or monthly ? Another option I see now is probably a smaller european conference when I read about this idea at the forums. Maybe spring or summer 2013 is a possible schedule. The problems you mentioned about travelling etc. is serious, but when we are looking for some sponsorship for conference location and accomodation maybe it's doable? We could try to collect money to pay flights for developers who have a good setting for the project, but no money left for travelling now. I will help to collect money and to organize such a meeting. I guess everyone has its prefs about location (see the forum post). I would recommend Switzerland of course, because James and Vivan can park their JU-52 here: http://www.airforcecenter.ch/index.php?id=25 , and because one could invite this guy http://www.rtw2012.com and he can not charge that much expenses . Or because the devs could visit this lab here http://www.sfly.org . Or because the Google Zurich Headquarters could sponsor an international video hangout in the nice old brewery they took. (They also took all the beer!). But ... maybe you know it already, Switzerland is not in Europe unfortunately. Sad, we need to look for another location. (Ok when we go along family size and children, then I will win a location contest probably). -Yves Am 02.12.2012 um 14:35 schrieb Curtis Olson : > The FS Weekend event has been the closest thing to a developer conference > that we've had over the past few years.Our developers are dispersed > across the world so any event would involve significant travel for most > people. For people with day jobs, young families, or tight budgets, > international travel can be a significant challenge. Everyone is in a > slightly different situation though, so attending an event might be doable > for enough people to make it worth while? With our size, it probably makes > sense to continue to piggy back on other larger events. > > Another thing that might be fun to try is a group skype call or google > hangout. I think you have to pay money for the high end version of skype to > organize a group skype call, but google hangouts are free. If there's any > interest in something like this it would be fun to try it out. I could > imagine a weekly "hangout" to discuss issues of the week, future > developments, etc. > > When FlightGear was first launched in the late 90's, group email was the way > these things were done, but now we have more options. For a google hangout > we have to deal with timezones around the world, and we'll never have a > perfectly convenient time for everyone. If you've never used google hangouts > before, you have to download a plugin for your browser (which is available > for windows, mac, linux) and then you need a google+ account. I propose > google hangouts because it's free to the end user (even though not > open-source), supports all the major platforms out there (and can even run on > smartphones or tablets), and as far as I know, there isn't an upper limit to > the number of participants in a hangout. > > But if anyone is interested in something like this, let's propose a time to > do a test. I think for many people they'll need to spend some time messing > around getting the plugin installed, getting their mike and video to work (if > they wish to show their face) :-) I got it running pretty quickly on linux, > but the true test was that I got it running on a mac and a windows box (which > means it can't be all that hard to get running there if I could do it.) :-) > > Curt. > > > On Sun, Dec 2, 2012 at 7:04 AM, Olivier wrote: >> Hi Yves, all, >> >> De : HB-GRAL >> Envoyé le : Dimanche 2 décembre 2012 12h12 >> >> > My dream: FlightGear should held a developer meeting once next year. >> > This would be my all time favourite. Have there been such meetings once? >> At least there were thoughts about doing a FG "Eurodev" conference ( >> http://www.flightgear.org/forums/viewtopic.php?f=18&t=8337 ) after the >> FSWeekend. >> >> FG is a very exciting project, where everyone can find a place where he can >> contribute depending on his skills, interests, ... Maybe something we are >> lacking is a kind of roadmap, so we can have a clearer view on the future. >> >> Olivier (silent, but working!) >> >> -- >> Keep yourself connected to Go Parallel: >> DESIGN Expert tips on starting your parallel project right. >> http://goparallel.sourceforge.net/ >> ___ >> Flightgear-devel mailing list >> Flightgear-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > -- > Curtis Olson: > http://www.atiak.com - http://aem.umn.edu/~uav/ > http://www.flightgear.org - http:
Re: [Flightgear-devel] FlightGear Usability
Hi James Am 12.08.2012 um 17:48 schrieb James Turner : > > On 11 Aug 2012, at 22:52, Martin Spott wrote: > >>> 3) Scenery. Terrasync is now built into FG, and we have nice UI to >>> configure it in-sim. However, it still requires users to set up a >>> separate directory and configure FG_SCENERY before it can be used. It >>> would be great if the standard installers created an >>> $FG_ROOT/WorldScenery directory with the appropriate permissions, and >>> added it to $FG_SCENERY by default. >> >> As far as I can tell, the value of "/sim/terrasync/scenery-dir" was >> already supposed to be added to the Scenery path, but I don't know at >> which priority. > > Right, this is all automatic now - has been since before 2.6 I think. At > least on Mac I set a 'correct' directory - in Library/Application > Support/FlightGear/Terrasync. Of course this is only a default, but for most > users it's enough. This is one of the 'correct' places of course. With FGx I put this folder (which I do not name "terrasync", I create a folder "TerrasyncScenery" or "TerrasyncData") into Users/Shared by default because of different reasons. One reason is that for the "common" user the Library Folder is hidden by default now on osx, the other reason is wanted to have an easy shareable place for different machines, so I don't need to terrasync for every machine. Because the Application Support directory is hidden by default I fear there will be some other posts in the forums soon "where is my terrasynced scenery", but maybe it's better to have a correct place then my not-so-correct FGx way for osx ;-) Do for consistency reasons it might be good to follow your changes here. Thanks, Yves > > If there's bugs / edge-cases that are not working, please report them and > they should be fixable, possibly with a couple of extra configuration options. > > Usability was the main reason for making terrasync be available as in-process > option, and I'm strongly considering doing the same thing for fgcom, although > that has a few extra complications. > > BTW, usability is also the reason I made the network options configurable > inside the sim, and have been making more subsystems support a clean reset, > so that it's possible to sanely control more behaviours with direct results > in the sim. > > James > > > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Environment Settings dialog
Hi Gijs Just for my understanding, does this still mean when you start in La Paz and you have no snow in metar the snow-level is set to 3000 meters by default? Or is there no snow at all? -Yves Am 11.08.2012 um 22:39 schrieb Gijs de Rooy : > Hi Stuart, > > > That might be worth thinking about, though I suspect it would be > > rather laborious to do so using property rules. > > Well, I did start this in Nasal, but Torsten converted it (incorrectly so it > seems; but that's not solely his fault) to property rules... :-) > > > My main issue with it is that it can result in the snow level moving during > > a > > cross-country flight. Some time last year, when there was some snow in > > Scotland, I found it quite distracting as the snow appear then disappeared > > seemingly at random as I was flying, depending on whether the nearest > > airport was reporting snow in their METAR or not. > > That sounds like it was caused by the bug I fixed today. Snow should not > dissapear (except when you fly over some terrain with lower elevation of > course). The snow level can only get lowered due to a METAR station reporting > snow at a lower elevation. The system never increases the altitude of the > snow line. The snow line does not change if a METAR station reports no snow > (actually "if there is no report of snow"). It simply stays where it was. > > When you fly into the range of a new METAR station that reports snow at a > lower altitude, then you will suddenly see snow appear at lower elevations > (might be nice to add some time filter for that actually, so it gradually > lowers). When you fly into the range of another station, the snow level will > stay the same, or lower even more. But it will never get highered. > > You are right that the behaviour I describe here was not seen up to today. > The snow line was really buggy before I commited today's fix, so please try > it again. I think you've got a needlessly bad impression of the system. > > > Fundamentally, I don't think that the METAR information provides a good > > enough proxy for the snow level. > > METAR can only report snow. It cannot report the absence of snow. And most > stations don't even report snow in the METAR (you've got SNOWTAMs for that; > where they give info like snowdepths and braking conditions for each runway). > So yes, it is only right in very few cases, but that's why I designed the > system the way it is (supposed to be). > > The system only comes in action when there is a pretty good reason to believe > there is snow. In any other condition; nothing is done. > > Cheers, > Gijs > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Environment Settings dialog
Can the snowlevel with this also go above 3000 meter ? -Yves Am 11.08.2012 um 19:58 schrieb Gijs de Rooy : > Hi Stuart, > > > I've just committed a new dialog - Environment Settings, which is > > intended to contain environment settings that aren't part of the > > weather settings, but shouldn't be in the rendering dialog either. > > Great! > > > - Added a control to enable/disable whether METAR controls the snow > > level through the metarinterpolator > > (/environment/params/metar-updates-snow-level). I'm not a big fan of > > this control, and I found it very difficult to work out why I couldn't > > set the snow level manually myself. > > The original intention was that it only overwrote your custom setting when > METAR reports snow at a lower altitude than that set by the user. So if > you've set it to 3000m, but a station at 1500m reports snow, the snow level > moves down to 1500m. You can then lower it even further, let's say to 1000m. > As the station altitude is now above the snow line, it will stay at 1000m. > Apparently this part was broken, as it was set back to 1500m after releasing > the mouse. > > I just commited a fix to Git (at least it works as I intended it to work > now), please check if that works for you. > > If the METAR reports no snow, nothing happens. Right now it only checks for > the nearest METAR station, but one could think of extending that to all the > METARS that are available in the property tree... > > Cheers, > Gijs > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery
Am 05.08.2012 um 19:07 schrieb Martin Spott : > Hi YVes, > > ys wrote: > >> A lot of scenery will come with 850 airport data either, and this is >> still refused by the core developers [...] > > Personally I don't like this sort of claims. > > After reading the above statement, the 'innocent' observer might > understand that swapping the current "apt.dat" file out of the Base > Package in favour of a v8.50 (or even more recent) file would be little > more than just a formal act. But that's plain wrong and does nothing > but raising false hopes. Hi Martin I'm one of this innocent observers myself. Flightgear can read 8.50 data, scenery tools are under heavy development to get it too. 8.10 data is deprecated by official xplane maintainers ... The only thing I miss since many months is a RFC how developers should work and how custom scenery with 8.50 (which is compatible to newer formats, 8.10 isn't) could come to official flightgear scenery. I don't want to 'claim' anything, I don't want to raise false hopes, it's just in responsability of the core developers to show how "2nd-row" developers can help to improve apt.dat without being blocked by a deprecated. I read 200 posts here about the "bigger picture", but none about how the work can be done step by step. -Yves > Instead you'd be breaking numerous dependencies by swapping "apt.dat" > files, therefore your claim has a connotation which I consider as being > inappropriate and misleading. > > In the past months (years) I've observed the topic of "how to organize > airport data" being covered with more different proposals than > available proponents, so far almost none of them having a reasonable > chance to survive in practical life, at least not for a coherent > Scenery. > > I'd appreciate someone taking care of the topic in a manner which takes > the "bigger picure" into account. I know you've started to do so, but, > as you already experienced, things tend to proceed a _lot_ slower than > you'd expect because there sooo much tedious detail-work to do. > > Cheers, >Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -- > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery
Hi Erik First of all the various custom scenery contributors have to start to communicate with each other and making a list of custom scenery available. This list should contain sources for custom scenery development, so GPL license incompatible scenery (i.e. scenery created with cgiar or osm data) can be kept out. A lot of scenery will come with 850 airport data either, and this is still refused by the core developers (they don't want to update apt.dat in fgdata the next weeks for 2.8.0 I guess). I tried to start a discussion about a new roadmap for scenery updates in the flightgear-scenery list, in the forums and at IRC, without that much success. Only a handful scenery developers take part, even there is some huge progress in scenery development tools. It's almost all prepared to get better world scenery at all ... but ... I guess only being a "scenery group" with a roadmap will succeed, because it does not depend on individual submissions only. So I ask you and others, please start scenery discussion in flightgear-scenery ML, make a schedule for meetings at IRC or elsewhere, start a RFC in wiki for scenery updates, a list of custom scenery projects and data available, help to compile better scenery laying around since many years (but be aware that it is not only a problem of placing some newer chunks on the main download page and make it available immediately). First question might be how scenery is distributed in general. -Yves Am 04.08.2012 um 09:59 schrieb Erik Hofman : > > Hi, > > When searching for some nice scenery spots for FlightGear to download I > discovered that everything on the site still refers to the 1.0.1 scenery > that was automatically generated in 2008. > > Are new scenery projects already integrated in the download map on the > site or do I have to search elsewhere. And if so wouldn't is be a good > idea to integrate all custom scenery chunk into the default, call it > 1.1.0 (or whatever) and offer it for download for the next release? > > Erik > > -- > http://www.adalin.com - Hardware accelerated AeonWave and OpenAL > for Windows and Linux > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
Hey Martin, you can get mine and I take (all) yours when FlightGear keeps that all in one window approach for the next ten years. But maybe the width is not that exact, I didn't measure my screen size for this 5 sec. scribble, sorry for that. Just wanted to keep file size small and clipped height for all the ML readers with 640 x 480 and modem connection. Cheers, Yves Am 25.07.2012 um 12:17 schrieb Martin Spott : > HB-GRAL wrote: > >> New GUI with separated menus/dialogs, viewer in a separate window: >> http://maptest.fgx.ch/screens/one-screen.png > > Someone please buy me a display *that* wide so I can still afford using > space lateral to the viewer for the menu ;-) > > Cheers, >Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -- > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
Hi Thomas, Hi James This looks promising in a technical/coding perspective of having this and that common GUI feature available also for flightgear. But for me personally one of the big problems of the FlightGear GUI is that it is "inside" the only and one main window. There is no possibility to have a separate window to not cover the main content, the scenery and the cockpit? This would make the GUI much more practical. I would really like to run flightgear with one window "view" and other windows for the program (options). This will improve the usability of all the menus, dialogs etc. a lot in my opinion. Cheers, Yves Am 25.07.2012 um 00:11 schrieb Thomas Geymayer : > Am 2012-07-24 19:35, schrieb James Turner: >> Thomas, one issue I can guess at (though PLIB is also really bad at >> it, and osgWidget is not much better!) - text selection. Do you think >> you'd be able to handle a blinking insertion point and a standard >> draggable text selection area in this approach? Obviously it might >> need some additional C++ helpers but that's okay since text-editing >> is a pretty specialised behaviour. > > Yes :) > > http://youtu.be/CIS8UyuJLgM > > I have just added some property change listeners to get the position of > the next character at a given position. The highlighting happens only > from Nasal. What is currently missing is the possibility to also change > the color of the selected text and to actually get the selected text, > but this shouldn't be too hard to implement. > >> One goal of mine for the GUI is to get platform native copy-and-paste >> working, BTW ;) > > This has already been on my wish/todo list :P > >> Obviously Thomas knows the Canvas code since he created it [...] > > Currently documentation is not too detailed, but looking at the > different demos and maybe also the Nasal API and source code should > help. If not, don't hesitate to ask :) > > Regards, > Tom > > -- > Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org > > Student of Computer Science @ Graz University of Technology > --- Austria > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
Am 21.07.2012 um 11:56 schrieb Harald Johnsen : > Mathias Fröhlich a écrit : >> >> >> ... >> But that means we could at the point where the warning happens compute the >> mipmap levels on the cpu in the loader thread. osg::gluScaleImage could be >> used to do this I think (or something similar not requireing a context). >> This one is an imported version of the original glu function that is >> included in osg for running on an EGL stack which no longer provides GLU. >> That is take the image scale this to the 1st mipmap, take the 1.st mipmap >> and scale this to the 2. mipmap and so forth. >> >> This would have the advantage that the png's do not deviate from the dds >> files over time. >> > > gluScaleImage does the usual job of blurring the texture to compute the > mipmaps. How does that look with textures that should fit seamless? I'm really not sure if this has to be taken into account, but when I use automated blurring (with any algorithm) I always get the same problem, the images/mipmaps loose and you will see structures and lines in the renderer because the textures do not fit seamless anymore. That's something ugly I also encountered in flightgear now with new texture work showing up, but maybe this is some texture work done with gimp/dds and automated mipmap creation, wrong compression or whatever, I don't know exactly. But would be really nice to see the result of automated/built-in scaling. > The advantage of pre computed mipmaps (inside .dds or not) is that we can use > better algorithms (http://en.wikipedia.org/wiki/Bicubic_interpolation or > http://en.wikipedia.org/wiki/Lanczos_resampling) to generate them. > Perhaps gluScaleImage could be upgraded with some more algorithms ; the > original code was trying to be fast but this is perhaps useless nowadays if > the code runs in a separate thread. > > Speaking with experience from RL work it depends heavy in which direction you scale. Bicubic might be good for scaling up and when you don't have to much details in a textures, when you scale down and have much detail in a texture it might be better to use "simple" bilinear, or sophisticated lanczos? I just started to use lanczos with gdal for tiff scaling and the result is promising. Cheers, Yves > HJ. > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGCom -> cmake
Hi Martin Did you pull, compile and test, any real feedback? Cheers, Yves Ps. We are aware of the next monster, thanks. Fgcom 1.2ff is working and still a nice piece. I guess you will find a lot of latest development from Holger Wirtz and Charles Ingels at sourceforge. I don't know if Holger Wirtz would find the time to guide someone trough the latest steps. And it's problematic anyway: Some newer fgcom code works a) with another license and/or b) still with iaxclient (which really is the most problematic part). PPS. Most wanted is still a proper asterisk/fgcom configuration like Csaba (?) runs it on fgcom server. Without such a configuration we are not aware of following the latest development steps anyway because we can't setup a test environment. Am 10.07.2012 um 21:06 schrieb Martin Spott : > ThorstenB wrote: > >> Schön wieder Fortschritte bei fgcom zu sehen. Und schön CMake + Git zu >> sehen ;-). Habt ihr auch mal Holger Wirtz kontaktiert? > > Unfortunately Holger is unable to contribute to FGCom any more, but > with a bit of luck he'll probably give access to his latest state of > develoment (which, as far as I know, is different from what's available > on Sourceforge). > > Cheers, >Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -- > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Hawaii regional textures merge request
Hi Thorsten Right, it doesn't look like it is worth to have a discussion about this and it was only me pointing this out. At the end I prefer to have your nice work in the repo and it's really not up to me to block anything. I'm just interested in this discussion and I remembered a lot of post about this topic earlier in flightgear development. I would vote to merge it in as an another example of nice and working regional textures, and maybe new people interested in a new approach for scenery development will establish a real collaborative effort later, starting to discuss, design and code, bringing up new ideas and find a place to communicate. The devel-list seems to be the wrong place for such at the moment. That's why I started the devel-scenery list, but this is completely ignored too. The only working channel I see at the moment is IRC #fg_scenery. Cheers, Yves Am 08.06.2012 um 09:49 schrieb Renk Thorsten : > > Okay, I didn't get a message that this was merged, and despite the argument > that there's need for a discussion of the regional texturing scheme there > wasn't any discussion, so can I assume the subject isn't interesting at the > moment, discontinue to try to come up with GPL compatible solutions (which is > hard...) and just continue my own texturing projects for my private > amusement? > > I don't have any issues with this not being merged, I just want to know. > > * Thorsten > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
Just to add a note what is already running on this jenkins right now, on different slaves: - hgtchop available SRTM-3 data (I make use of the no data filled files I provide), this a one day job on very old machine - terrafitting the data (another one day job on the same old machine) - taking recent xplane apt.dat and splitting into single airport files (one hour job) - creating xml files like showed at scenery list, per airport, still experimental - running genapts850 on every single airport file, creating airport and airport area folders for further scenery creation, still experimental - pushing this data to a public server (not realised yet, waiting for proposals where this should be) This is all created in a jenkins workspace which can be shared then by fgfs-construct slaves. What regions or how many tiles this slaves could/should create depends on a new "regional" grid that has to be defined. One benefit of this workflow could be: Everyone use the same elevation data for scenery creation, everyone use the same apt.dat data etc. The fgfs-construct job definitions may vary from region to region. People can concentrate on updating resources and jenkins scenery slaves are eating this automatically. Theoretically every machine around the globe can act as a jenkins slave when the recent terragear toolchain is installed and distinct ports are open in network. The fgfs-construct jobs are heavy and may run some days. Having some powerful servers as "main" slaves would be nice. Role for main slaves could also be taking over the jobs when some smaller nodes are off for any reason. Yes, just promoting this jenkins world scenery workload idea again, comments still welcome anytime. In case there is a machine/server which can act as a slave please just send me a note. You can get access to this jenkins immediately, I would also help to install all tools and setup the jobs to be done ;-) Cheers, Yves Am 07.06.2012 um 17:35 schrieb ys : > As I mentioned some weeks ago I think we should leave path of creating world > scenery in one task. I made a proposal how to create world scenery in chunks > all day and nights with jenkins on different machines for different regions. > The sources for this creation process can remain on one "master", the many > fgfs-construct slaves will need a bit of cpu power (more slaves welcome here > anytime for testing). What I miss at the moment is a tool like terramaster > for this process, where one can follow recent scenery creation process by > created tiles i.e. The jenkins artifacts can be pushed to a terrasync server, > daily, weekly, monthly or in whatever cycle. A tool like terramaster should > reflect the versioning of the region/tiles visually somehow, but this is not > the most important part of course. > > For me the scenery release should not follow the core release plan. A need > for the next release cycle might be moving the outdated static apt.dat from > the base package to a new place, but of course only in case someone really > follows the plan to get a dynamical apt data solution for next flightgear. I > know the plan with jenkins scenery creation might cause some inconsistency > the first weeks and months, but once the creation process is in sync with > data there remain only small areas to update and we can follow regular and > great apt.dat updates coming in every months by a huge group of contributors > chez xplane. > > There is probably no other way (or I didnt here anything different here): > apt.dat in 810 format is a scenery development blocker, independent of > release numbers. > > Cheers, Yves > > > > > Am 07.06.2012 um 15:55 schrieb Björn Kesten > : > >> Good to know. >> >> I'd dedicate some CPU time to world scenery generation, but I'm not >> sure how many months that would take... :S >> >> -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> ___ >> Flightgear-devel mailing list >> Flightgear-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Di
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
As I mentioned some weeks ago I think we should leave path of creating world scenery in one task. I made a proposal how to create world scenery in chunks all day and nights with jenkins on different machines for different regions. The sources for this creation process can remain on one "master", the many fgfs-construct slaves will need a bit of cpu power (more slaves welcome here anytime for testing). What I miss at the moment is a tool like terramaster for this process, where one can follow recent scenery creation process by created tiles i.e. The jenkins artifacts can be pushed to a terrasync server, daily, weekly, monthly or in whatever cycle. A tool like terramaster should reflect the versioning of the region/tiles visually somehow, but this is not the most important part of course. For me the scenery release should not follow the core release plan. A need for the next release cycle might be moving the outdated static apt.dat from the base package to a new place, but of course only in case someone really follows the plan to get a dynamical apt data solution for next flightgear. I know the plan with jenkins scenery creation might cause some inconsistency the first weeks and months, but once the creation process is in sync with data there remain only small areas to update and we can follow regular and great apt.dat updates coming in every months by a huge group of contributors chez xplane. There is probably no other way (or I didnt here anything different here): apt.dat in 810 format is a scenery development blocker, independent of release numbers. Cheers, Yves Am 07.06.2012 um 15:55 schrieb Björn Kesten : > Good to know. > > I'd dedicate some CPU time to world scenery generation, but I'm not > sure how many months that would take... :S > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
Hi Torsten What are the plans now for apt.dat.gz and nav.dat.gz ? Will this prehistorical data files still be shipped with flightgear base package 2.8.0 ? As far as I understand flightgear is ready to read the newer formats and also the airport scenery tools are ready to use the newer formats. And there are some tendencies to keep this data out of the base package anyway and having a new organized data distribution (which is my favorite). I am still comparing 810 data with 850 data for some older airport work done by flightgear contributors. Once this task has finished I will send converted data to the xplane database to be integrated where it makes sense and where I couldn't find original contributor (some airports have already been updated meantime by xplane contributors, so it is necessary to compare every airport and decide which one has more advanced or "better" data). I think it is a good choice to go for the new data format even because contributors are asked to send their edits to robin peels xplane datacenter since many years. Unfortunately 810 xplane data format will not be updated anymore, so without roadmap for a change there is only the possibility to have a own flightgear data distribution, missing huge updates from the last couple of years probably. On the other hand some terrasynced scenery data will be out of data sync probably for some months with the change, but I guess this is the part which can be updated out of core release cycles and base package anyway. Cheers, Yves Am 02.06.2012 um 21:36 schrieb Torsten Dreyer : > Hi, > > in just a bit more than two weeks from now we reach June, 17th, marking > the first milestone for the release of next FlightGear version: the > "feature freeze" period. > > If you have some great and exciting new features for FlightGear on your > local disc but not yet pushed the gitorious repository - now is the time! > > Two questions have to be discussed and answered until the release > branches get created on July, 17th: > > 1) What's the version number of the new release? > a) 2.8.0 > b) 3.0.0 > > 2) Which aircraft do we ship in the base package? > a) just the c172 > b) same as before > c) [name your preferred aircraft] > > 3) Should we keep last year's commit policy for aircraft during the > feature freeze? > a) yes > b) no > > Regards, > Torsten > > > > > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
