[Flightgear-devel] Segfault in current master when specified aircraft could not be found
Hi! When starting fg with an invalid aircraft, it segfaults after printing the message: Cannot find specified aircraft: 777 Program received signal SIGSEGV, Segmentation fault. 0x77970d44 in pthread_mutex_lock () from /lib64/libpthread.so.0 (gdb) thread apply all bt Thread 5 (Thread 0x7fffeb6c6700 (LWP 7390)): #0 0x7797539d in write () from /lib64/libpthread.so.0 #1 0x720f5166 in ?? () from /usr/lib64/libstdc++.so.6 #2 0x7212d02f in std::basic_filebuf >::_M_convert_to_external(char*, long) () from /usr/lib64/libstdc++.so.6 #3 0x7212d913 in std::basic_filebuf >::overflow(int) () from /usr/lib64/libstdc++.so.6 #4 0x7212b41f in std::basic_filebuf >::sync() () from /usr/lib64/libstdc++.so.6 #5 0x7210de0e in std::ostream::flush() () from /usr/lib64/libstdc++.so.6 #6 0x00e180e3 in LogStreamPrivate::run (this=0x139a8a0) at /home/nine/install/FlightGear-0.9/simgear/simgear/debug/logstream.cxx:222 #7 0x00ea801a in SGThread::PrivateData::start_routine (data=) at /home/nine/install/FlightGear-0.9/simgear/simgear/threads/SGThread.cxx:204 #8 0x7796ee0f in start_thread () from /lib64/libpthread.so.0 #9 0x7189c7dd in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x77f98840 (LWP 7383)): #0 0x77970d44 in pthread_mutex_lock () from /lib64/libpthread.so.0 #1 0x00e1608c in SGGuard (l=..., this=0x7fffd1f0) at /home/nine/install/FlightGear-0.9/simgear/simgear/threads/SGGuard.hxx:18 #2 sglog () at /home/nine/install/FlightGear-0.9/simgear/simgear/debug/logstream.cxx:356 #3 0x007191a5 in FGGlobals::saveUserSettings (this=this@entry=0x139aa90) at /home/nine/install/FlightGear-0.9/flightgear/src/Main/globals.cxx:527 #4 0x007197a7 in FGGlobals::~FGGlobals (this=0x139aa90, __in_chrg=) at /home/nine/install/FlightGear-0.9/flightgear/src/Main/globals.cxx:182 #5 0x00719c69 in FGGlobals::~FGGlobals (this=0x139aa90, __in_chrg=) at /home/nine/install/FlightGear-0.9/flightgear/src/Main/globals.cxx:220 #6 0x717ebf61 in __run_exit_handlers () from /lib64/libc.so.6 #7 0x717ebfe5 in exit () from /lib64/libc.so.6 #8 0x00720966 in fgMainInit (argc=2, argv=0x7fffd8f8) at /home/nine/install/FlightGear-0.9/flightgear/src/Main/main.cxx:342 #9 0x006e3b14 in main (argc=2, argv=0x7fffd8f8) at /home/nine/install/FlightGear-0.9/flightgear/src/Main/bootstrap.cxx:244 I can reproduce the segfault every time. Btw. don't let the 0.9 distract you. I just have never renamed my build directory. Regards, Stefan -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Howto download aircraft ( and others data ) from Git
On Tuesday 03 September 2013 11:51:34 Saikrishna Arcot wrote: > *: Technically, a torrent download of the bundle would allow you pause > and resume, so if there are cut-outs, you won't have to restart. That > being said, downloading 5 GB on a phone line will take a long time (a > week?). Actually you don't need a torrent for pause/resume. Just a tar bundle of the repo on an http or ftp server and wget -c like already suggested. > In the long term, according to James, the repo will be > reorganized such that the sizes are smaller. I hope with the reorganization we don't lose the simpleness of doing a git pull to get the latest and greatest of all aircraft. Having to look for scattered repos would be a severe drawback. Stefan signature.asc Description: This is a digitally signed message part. -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Article about non-profit organizations for free software
Hi! we had the discussion a while ago and now lwn.net published a great article on the subject: http://lwn.net/Articles/561336/ According to http://wiki.flightgear.org/Project_Infrastructure_Enhancements it's still an open issue on how to handle donations to FlightGear. Well worth a read, Stefan signature.asc Description: This is a digitally signed message part. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
On Thursday 20 June 2013 17:55:40 grtuxhangar team wrote: > I guess the professional you are has done statistics about the FG users > world, thus you are able to be more precise about those unfortunate users > who are getting only "the single frame per second", which hardware? which > operating systems ? With an AMD Radeon HD 5670 using free radeon driver I've never seen performance of more than 15fps with Rembrandt and if I turn shadow details up so they don't look crappy I get about 3-4fps. So yes, we do exist. So can you please stop the insults and take your arrogance elsewhere? > Regarding ALS i never said we must have the entire ALS pack with Rembrandt > , we should be able to split it in order to choose which part is good and > working for the user. All parts of ALS work perfectly fine for me and I get between 15 and 30fps. Perfectly usable. Stefan signature.asc Description: This is a digitally signed message part. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
On Saturday 27 April 2013 13:31:33 Vivian Meazza wrote: > What is the real problem? I've got a little list: > > I don't want to download fgdata/fg/sg to find that I have to spend > hours fixing up my work. I'd rather get on with my own stuff. > > I don't want to download fg/sg to find that it won't build. > > I don't want to download fgdata to find things which "used to work". > > I don't want to have frame-rates of less than 40 and/or jittery. Well then the problem cannot be as large as it looks like since ALS does not cause any of those. > I don't want to force users to choose between a nice atmospheric > effects or shadows, or anything else. > > I don't want to force developers to develop ac for one > scheme/framework rather than another. Then why have I not read a single email about how Rembrandt diverges from the default rendering scheme and forces users to choose or that aricraft developers have to make adjustments? I only read about ALS which is much less of a problem, since I can use any airplane with it and can turn it on or off at runtime without a problem, so as a user I don't have to decide up front. > I don't want to open the Devel List to find yet another storm with > Thorsten at the centre of it. > > And finally - I feel really strongly about this one: > > I don't want anyone to feel that they have to leave the project > because of acrimonious discussions on this list or anywhere else. It has > happened only rarely, but I regret each and every one. So why are you with those who are driving Thorsten away if you feel so strongly about this point? If you don't want a shit storm why are you happily contributing to it and siding with people who call others racist just for refusing a huge feature commit during a feature freeze? > I know this is unrealistic, but we should all be striving along these lines. > > I'm horrified that you have received hate-mail. This is only a flight sim > for goodness sake. We have a long tradition here of friendly and orderly > debate. These are probably the most reasonable sentences within this whole debate. Regards, Stefan -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
On Thursday 25 April 2013 15:41:54 henri orange wrote: > Here is quoted Renk sentence himself: > "I hope you have the fairness to ask FredB to remove Rembrandt then as well, > because we need to ship the default rendering scheme such that users > without good graphics cards..." I know, you cited it the first time as well. But it simply does not mean what you obviously think it means. That's why I kindly asked you, to have someone explain it to you in your native language. Thorsten only said, that _if_ you ask him to remove ALS because of concern for users without good graphics cards, you should aks FredB as well to remove Rembrandt, because the same argument would apply. Not doing it just shows that different standards are applied which is simply unfair. > Does'nt ATI known to be the wrong choice to play FG ? No it doesn't. To cite http://wiki.flightgear.org/Supported_Video_Cards "you should be fine with any Nvidia or AMD/ATI products having 512-1024MB of *dedicated* video memory". > Said before you are in difficulty because of ATI. Ok, so I'm in difficulty because of ATI (which do not even exist anymore, it's been AMD for 7 years now) and therefore Rembrandt is ok. But if you have problems with ALS, it's not your NVIDIA hardware that's the problem, but ALS. Because clearly, your hardware is more important than mine and FG developers should develop for your system only. Right? > I know my english is wrong, however, i know the difference between VARIANT > and OPTION. > Right know there is options with shaders , clouds weathers etc. > Variants with Rembrandt and ALS. So please enlighten me and tell me what in your eyes is the difference between a variant and an option and why the distinction is important. As a user, I can simply decide at runtime if I want ALS or not by clicking a checkbox in an options panel. So why is ALS a problem for a user who doesn't want to use it? Regards, Stefan signature.asc Description: This is a digitally signed message part. -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
On Thursday 25 April 2013 14:45:05 henri orange wrote: > So, your long answer to explain you don't like Rembrandt and you prefer to > work on your own system, as just been underlined there by you. > Your conclusion is "REMOVE REMBRANDT and keep up my own development" > This clarify to everybody your approach. > You want a flightgear without Rembrandt. Thorsten did not even remotly say anything like that. Your accusation is completely uncalled for. If this is what you read in his last email, please try to find someone who reads Thorsten's English the way he meant it and have him explain to you. It would be a shame if a solution would fail due to a language barrier. > You claim Rembrandt wants high level Hardware my 9600 GT 512 mb can process > it. With An average of 20 fps ( disabling rembrandt and without ALS i never > get more than 30 fps). On a Radeon HD 5670 I get 3 (in words: three) FPS with Rembrandt using the free radeon drivers with lots of graphics problems and very ugly shadows. On the other hand I get solid 15-20 FPS using ALS and pretty maxed out quality. > Your ALS systems wants (when it is not crashing my system) a higher level > capacity Hardware ( mostly GPU ) to work correctly, with every features. Maybe. On some systems it ALS might be a problem, on others it's Rembrandt. > You told us you had the most perfect equipment , you can't evaluate what is > good or wrong with low level equipments. And you have only your own system for comparison. Just like I only got mine. And yours and mine certainly don't match. So while maybe Thorsten cannot give general adivse on FG's performance on low level equipment, neither can you and neither can I. > I don't mean i don't like ALS, i mean i don't like your approach , instead > of working on consistency with the existing valuable features which were > implemented within FlighGear, ( and by including Rembrandt), you ARE > WORKING on a other FlightGear. > > You are working on a flightgear VARIANT, your work is not OPTIONS to > flightgear. I can start FG, go to the rendering _options_ and turn ALS on and off, at runtime, as often as I like. How is this not an option? > Others , better than me, tried before me to tell you, you (are) were on > the wrong way. And Thorsten time and again explained on solid technical grounds why he implemented it the way he did, why he had to and what the consequences of other approaches would have been. I have to date not seen anyone even acknowledge these reasons, much less provide real arguments against them. Why Thorsten has not given up on this yet is just beyond me. This is not a discussion, it's just handwaving and accusations. I'm just very glad, that he didn't give up. So instead, I can enjoy as much of the great flying experience as I can get during the long winter months. And just to be clear: I'd love to have all the goodies combined. Very nice shadows provided by the Rembrandt defered renderer combined with stunning ALS visuals and correctness and the performance of the default renderer with all effects turned off. But that's simply not possible, so instead I enjoy what _is_ possible. Regards, Stefan signature.asc Description: This is a digitally signed message part. -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
On Thursday 25 April 2013 01:34:12 henri orange wrote: > It is not the Atmospheric Light Scattering, we want. > > Referring to your explanation, and some other talks you had with Emilian ( > who unfortunately gave up ), you are ignoring the flightgear users > community interest. > It is not the Atmospheric Light Scattering, we want. Please do not pretend to speak for all FlightGear users. You may certainly speak for yourself, you may even represent some part of the users, but you do not speak for all of us. I am a user and let me make this clear: I love Atmospheric Light Scattering. I love that it makes the view in the simulation match almost perfectly what I see outside the window. For me as a VFR pilot, visibility is one of the most important parts of a simulation and ALS doesn't only get it right, it also looks stunningly beautiful at that. > We want, so far, a consistent flightgear system, any features should be > compatible each other, and not breaking each other. If you ask me, the way to achieve that is to just drop the default rendering scheme. It's clearly inferior and makes FG look quite unprofessional. But even though the free radeon drivers are nowadays good enough to allow me to use ALS, some people simply have not the hardware necessary for good performance. And for them the default rendering scheme may still have use. > What about Rembrandt ? To reproduce the reality, isn't it the main tool > which gives the best effect ? Won't the effort should done on that side ? Like for some people's machines ALS might be too much, Rembrandt certainly is too much for mine. Last time I tried, I still get graphics corruption and poor rendering performance, so it's not an option for me. And as I said, there are people with less powerful hardware than me. So if FG would only use Rembrandt, it would leave plenty of users behind. > I hope that the next Flightgear version will offer a consistent system and > not several independents systems ( including your Flightgear) which won't > be compatible each other. What about Thorsten' arguments? Why is it so important for _some_ users that the different rendering schemes support exactly the same features. Or in other words: why should ALS users have to forgo very nice features, just because the default rendering scheme does not support them? And why do you think Thorsten is responsible for implementing all features in all rendering schemes? If certain features are so important for you, why don't _you_ contribute? This is free software after all. Regards, Stefan -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard bindings
On Monday 04 March 2013 15:38:45 James Turner wrote: > You're the third person to say the same thing. But again, you don't actually > want to change the FoV at all. What you're doing (and everyone else) is > using this feature to look around 3D cockpits, right? In other word, our > cockpit navigation UI needs some improvement :) I do not only use FoV in 3D cockpits, but also as zoom in outside views. For example in the look from tower view. Though it's not essential, it's a use case. Stefan signature.asc Description: This is a digitally signed message part. -- 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] Advanced Weather updates
On Sunday 03 March 2013 11:56:44 Vivian Meazza wrote: > James Turner > > > On 3 Mar 2013, at 10:29, Vivian Meazza wrote: > > > Well gitorious is good for something! The patches still exist! I've > > > put them here if anyone wants to do something with them: > > > > > > https://www.dropbox.com/home/Public/Patches/MoveModels > > > > Dropbox won't let me in, can you email me the patches? > > Dropbox won't let you in! Why not? Did you offend it in some way? Have you > been black balled? Same here. I just get some Sign in page. Stefan -- 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] FG vs. FSX demo
On Wednesday 27 February 2013 09:10:01 Vivian Meazza wrote: > Linear features for the scenery (roads, railways, rivers) are already under > development for FG: > > https://dl.dropbox.com/u/57645542/fgfs-screen-129.png > > That is a small area of Kent, UK. It is very possible to use the accurately > placed features for VFR navigation. Yeah! That's great news :) Thanks to everyone working on FG! Stefan signature.asc Description: This is a digitally signed message part. -- 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] FG vs. FSX demo
On Wednesday 27 February 2013 07:42:19 Renk Thorsten wrote: > * A big plus about the FSX terrain is that it doesn't have landclass seams. > That makes it quite a bit nicer to look at from above. It's not so > impressive from close-up, and all in all, I would conclude that regions > where we did apply a regional texturing scheme and use the best shader > effects available are in fact quite competitive. In particular, I think the > recent 2nd generation Hawaii in FG or middle-east looks much better from > close-up and is still about on par when seen from a few thousand feet. Of > course, FG terrain can look much worse in areas where we didn't customize > it. > > -> Pretty much a draw. Hiding the landclass seams better would still be the > thing for FG.. it's just not so easy. A small addition: what has always bothered me about terrain in FG is that roads and rivers are all the same size. For me as a VFR pilot they are the most important navigation helpers while in FG, they are useless. There's no difference between the Autobahn and a small country road. Same for the Danube vs. some riverlet. I've tried some version of MS Flightsim once with Austrian scenery and could easily find my way around. So while we may have the prettier scenery with regional textures, in practice, I'd have to call it a win for FGX. Regards, Stefan -- 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] download_and_compile.sh one git repository or serveral.
On Sunday 24 February 2013 22:18:05 Pat wrote: > > > Anders made a suggestion on IRC I'm going to follow up on. " You can > > > have local git clones that share the same .git/* files via file > > > links" > > > > ..you feed 4 build trees from 1 git clone, how? > > A "du -sch $git-n-build-trees" on them all? You probably don't want to symlink all the files in .git. You just want to symlink the objects subdirectory. This is the place where all the real data is and it would be the same for all local repositories. The other files list for example branches and tags and very important: the currently checked out branch. So if you want several local repositories with different branches checked out, you may not share these files. So in essence, you have one plain normal clone of the repository: git clone git://... fg-master For the other repositories, you could set them up like: # create a local clone (no download) git clone fg-master fg-whatever # copy the config of master so both use gitorious as remote cp fg-master/.git/config fg-whatever/.git/config # replace objects in the clone by the symlink rm -Rf fg-whatever/.git/objects ln -s fg-master fg-whatever/.git/objects Repeat these steps for all the branches you want to test. This gives you several local clones of the repository which can have different branches checked out and which share the meat of the repository data. You can work in them just like in any normal repository. Just do the usual git pull / git checkout / ... When you do git pull, git will download new objects and then merge the remote into the local branch. It should not matter in which branch you download the new objects since git does not change old ones. Just don't do any history changing like git rebase. > > ..you only do an e.g. "git branch 2.10 ;git checkout", Btw. the shortcut would be just: git checkout -b 2.10 creates the branch and checks it out. Stefan signature.asc Description: This is a digitally signed message part. -- 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] Low visibility issues
On Sunday 24 February 2013 18:46:08 Vivian Meazza wrote: > I'm probably a day late and a dollar short here - but try as I will so far > I've failed to find a visibility slider under environment->weather. It's > probably staring me in the face - but could someone point it out to me? In the Weather dialog: Model overall weather conditions based on METAR Advanced Settings Thermic Visibility and Settings Max visibility Stefan -- 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] Low visibility issues
On Saturday 23 February 2013 13:20:49 Emilian Huminiuc wrote: > Guess what happens when memory is limited and visibility is set to 120km? > You see the "end of the world", because no more tiles can be loaded to reach > that distance. > Guess what you need to adjust then, independent of what the "real world" > says? Visibility distance (implicitly fog) to mask it. I just tried it. Turned off random trees, objects and buildings and set visibility to about 120km using the z key with basic weather. fgfs used about 960MB of memory. That's about 4€ worth of memory and well below any 32 Bit limit. I do have automatic scenery download enabled and it did not see a reason to download anything, so I'd say I do have the scenery tiles for this visibility range. > Regarding trees: you think that way, I might, someone else in the know might > too, but the average user sees that they work well with his setup in the > default condition, why would he want to disable them? He doesn't. Because he doesn't know they use so much memory. Instead he fiddles around with something that according to my test actually doesn't seem to help all that much. > The only thing that new setting advertises is it reads the METAR string in > a more advanced way... There are plenty of other options that do not advertise in any way how they affect memory usage. So it would seem that advanced weather simply sticks to what's considered normal for FG features. > Manual setting of this has the added benefit that you're not moving tiles > back and forth through the tile cache/display as memory becomes more or > less available. You set a max setting that suits your machine and or the > area you fly in (in the carribean you can easyly reach that 120km, not so > much at KLAX) and you're done with it. And how do I as a user know how much visibility I can afford? Do you suggest the solution for users is to do trial and error until he finds a setting where FG doesn't crash 5 minutes before landing? I just can't see how this would be better than FG just being more intelligent about memory usage. > And why should you have to set that in _n_ places, when there was a > perfectly reasonable documented setting in the first place. Why do you want the user to have to repeatedly press a key after starting the sim instead of setting the maximum visibility once and for all in the advanced weather dialog? In other words: why should the user press a key _n_ times instead of setting a slider once? > This thing with the visibility is just one part of a bigger problem here, > that someone doesn't want, or doesn't uderstand that he has to take > shortcuts, use tricks, and abdicate from a faithfull model of the real > world. Instead he shoves everything but the kitchen sink in, disregarding > what effects that might have, expects everyone else to accomodate any needs > that might arise from that And I'm very very grateful for this. As a glider pilot I can't express how much I love having even a somewhat realistic simulation of weather and atmospheric effects. You know what's also great about it? It's all optional! If a user doesn't care about all these realistic details, he can just turn them off. Or even more: not turn them on since they are off by default anyway. > and considers any bit of critique or negative > comment as a personal affront. This is simply not true. While I think that sometimes Thorsten may give people more benefit of the doubt, I'm actually very impressed with how civilised and patiently he reacts to criticism and how much time he spends explaining his rationale. Your statement is untrue and unfair and does not belong to a technical discussion. Stefan -- 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] Low visibility issues
On Saturday 23 February 2013 12:21:02 Emilian Huminiuc wrote: > So in the default scheme we load 9 tiles at startup, then we keep loading > tiles in the direction we're traveling, and those initial tiles remain > resident in the tile cache for a while (in case you decide to double back). So there's a bug in the tile cache. When caching stuff leads to an out of memory condition, the cache is at fault. The whole purpose of such a cache is to improve performance. A crashed application has the worst performance of all. So this cache should be fixed to automatically reduce the number of cached tiles in low memory conditions. > Well, our average user might have read the manual, might have mucked about > with the visibility setting before, and he remeber that all things being the > same, visibility is what impacts performance/memory the most, so he decides > to try again, this time trying to use z/Z to limit how far the visibility > goes, maybe he gets lucky and it won't crash again, but he's in for a > surprise... z/Z doesn't work... So the manual is wrong as well. Like you said yourself, trees give a larger memory hit than terrain. So the first thing to do should be to disable trees. > You might argue that he should know better, go into the advanced settings > dialog, figure out what all those sliders and selection boxes do, etc, > etc... But remeber, our user is an average one, he wants things to just > work (with time, he might find a use for the more advanced configuration > stuff, but for now he's not interested, he just want to click something, > and be done with it), The z/Z case above might be a lucky one where he > might have read the manual. Since advanced weather seems to have a slider for maximum visibility, why not change the key binding to make z/Z control this maximum visibility? This still leaves control of visibility with advanced weather but should satisfy the people using this key for memory management (however wrong that approach may be in my opinion) > You look at view-distance/fog just as an atmospheric phenomenon, that you > think should be represented verbatim, well it's not. It's not just that in > any case, and if for it to fulfil all its roles you need to abdicate from > the verbatim aproach, well then I'm sorry but my opinion is that you > should. I never claimed that it's the only resource management device, I > only claimed that it's role is much more than just visual cue to the > environment, and that role should not be underestimated, or thrown aside... >From this whole discussion I get the impression that FG's memory management simply sucks. We have caches eating too much memory at times, several memory intensive features but no information about how much memory they really use. Yet still we push responsibility for keeping memory requirements within the limits of his machine to the user. The one who has the least chance of getting it right. The solution is not to give crude tools like limiting visibility to the user. The solution is to fix FG to be consious about how much memory is available and make the best use of it. Yes, many games simply limit visibility if memory or performance pressure gets high. But FG is a flight simulator. Visibility is a very important part of flight (at least for me as a VFR pilot). Stefan -- 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] Discussion culture clashes
On Saturday 23 February 2013 07:33:54 Renk Thorsten wrote: > -> I agree with Vivian, we can't do realistic distances for radar because of > memory issues > Lorenzo: > > the reason to be of the EQUIPMENT is to override the limit of the EYE > > vision. > > Are we doing the error to merging this two ? > > -> Assumes that we want to set the limits by equipment (radar) rather than > visuals, although we've just said we don't want to do this because of > memory issues, and I've listed several points besides radar why I'd like to > do it. Actually, I think what he tried to suggest was, that the needs of visuals and the needs equipment like radar should not be mixed. For visuals we need the terrain and all the objects like trees and buildings which are hard on performance. For radar we would only need a probably simplified form of terrain and can easily do without all those objects. So even 200km of radar range could be implemented without hitting too hard on memory. Essentially he was asking for some kind of LOD, be it automatic or manually by having separate data sources. The language barrier makes it somewhat hard to be sure, but that's how I interpreted his original message. Stefan -- 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] Color-shifts for textures
On Monday 28 January 2013 08:46:02 Renk Thorsten wrote: > Well, yes, that I know - this is why the performance/quality steps in the > framework utilize mostly different shaders rather than one shader with > if-statements. > > But we were talking about *optional* usage of the framework making things > worse for everyone else, and none of the shaders concerned are even > compiled unless they're switched on. Sounds to me like this discussion could use some more concrete examples to make sure all involved understand the things said and talk about the same. Mathias, could you please give examples of the code you were talking about? Stefan signature.asc Description: This is a digitally signed message part. -- 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/learnnow-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Color-shifts for textures
On Monday 28 January 2013 08:02:14 Renk Thorsten wrote:
> > Any
> > additional uniform takes time to be set up in the driver. Any code that
> > is in the shader and that cannot be optimized away at *link* time of the
> > shader may
> > take registers which affects the partitioning and the amount of paralell
> > executed threads in the GPU.
>
> You mean to say a shader which isn't even compiled takes away performance?
> (A non-functional shader doesn't throw a compile error unless it is
> actually switched on in the GUI, so they don't seem to be compiled up-front
> just in case).
No, I think what he meant is that (without me ever even seeing shader code)
something like:
if (enable_light_scattering) {
a = b + c;
}
compromises performance, even if light_scattering is disabled because the
compiler would assign registers to this code (the a = b + c), even though it
will never be executed. These registers could be used to more efficiently
execute the code that actually runs.
Stefan
signature.asc
Description: This is a digitally signed message part.
--
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/learnnow-d2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear windows compile- mathlib.c/test_state_machine
On Wednesday 23 January 2013 13:48:44 Alan Teeder wrote: > I think that we all know that, but unfortunately it is something that we > have to live with - FG is multiplatform. > > Sorry - but please don´t blame the messenger. ;-( Wouldn't it be possible to compile this file in C++ mode? That's the course the Parrot project follows. > -Original Message- > From: Frederic Bouvier > Sent: Wednesday, January 23, 2013 10:45 AM > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Simgear windows compile- > mathlib.c/test_state_machine > > > De: "Alan Teeder" > > > > Just a heads-up. (MSVC10) > > > > Alan > > > > 3> mathlib.c > > 3>C:\FlightGear\simgear\simgear\nasal\mathlib.c(130): error C2143: > > syntax error : missing ';' before 'type' > > 3>C:\FlightGear\simgear\simgear\nasal\mathlib.c(131): error C2065: > > 'range' : undeclared identifier > > 3>C:\FlightGear\simgear\simgear\nasal\mathlib.c(131): error C2065: > > 'range' : undeclared identifier > > Reminder to all : MSVC is not C99 Compliant. It doesn't like C++ style > variable declaration inside the body of a bloc signature.asc Description: This is a digitally signed message part. -- 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/learnnow-d2d___ 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
On Wednesday 28 November 2012 18:05:53 Arnt Karlsen wrote: > > Is there a way to manage packaging across distros? > > ..not _a_, but _many_ ways. Debian probably has the best > (and biggest) pile of tools to do this, I have this vision > of somebody running this virtual build-n-test cluster off > his git tree from a laptop, or some such. Visions are nice, links are better: https://build.opensuse.org/package/show?project=games&package=FlightGear https://build.opensuse.org/package/show?project=games%3AFlightGear%3AUnstable&package=flightgear A good first step would be to contact the maintainer of the FlightGear package in the games repository and ask why build is disabled for all non-openSUSE distributions. Stefan -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ 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
On Tuesday 27 November 2012 07:56:02 Renk Thorsten wrote: > > Binary releases on Linux are /possible/ but a pain - working with each > > distro's packaging system is definitely the way to go, in my opinion. > That basically seems to require that everyone who wants most recent FG needs > to update to most recent Linux. No it doesn't. There's nothing preventing us from providing packages for older distribution versions. On the openSUSE Build Service it's usually just selecting the versions and packages will get built automatically. Stefan -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ 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
On Monday 26 November 2012 09:45:51 Renk Thorsten wrote: > I am genuinely at a loss here. A normal Linux user has practically no change > to get last stable on his box running if it isn't in his distro - a normal > Windows user gets everything nice and streamlined. > > Does anyone else understand this? Linux != Fedora. There's obviously only outdated packages for Fedora. But that's a problem that can be fixed. As an openSUSE user, I have the choice of FlightGear 2.8.0 in the games repository, or 2.9.0 in games:FlightGear:Unstable thanks to the openSUSE Build Service. I just have to look for "flightgear" on http://software.opensuse.org/search, "Show unstable packages" and hit "1 Click Install". Nice and streamlined indeed. The nice thing is: the openSUSE Build Service is not limited to openSUSE. Packages can be created for Debian, Fedora, Mandriva and Ubuntu as well. And once you got that set up, it's very little work to maintain. I think this could be a great way to make FlightGear better available to Linux users. Stefan signature.asc Description: This is a digitally signed message part. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Merge request #181
On Friday 05 October 2012 07:01:37 Renk Thorsten wrote: > * take a clean copy of a rebased master into a new branch > * edit in all the changes I want to have in the merge request, copy in all > new files * do a merge request from there rather than from my actual devel > branch > > But this doesn't seem to do what I intend (?) Merging is done at branch level, so it's either the full branch or nothing. So to have separate merge requests you have to use separate branches. Create one branch for each feature (based on current origin/master) and use git cherry- pick to import only the relevant commits for the branch. Then you can send merge requests for these branches. Stefan -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] another git question
On Tuesday 02 October 2012 21:07:58 Curtis Olson wrote: > I have a clone of the repository on my embedded system too, and it's remote > is setup to point to the clone on the thumb drive when that is plugged in. > So I can plug the thumb drive into my main linux computer and run > pull/push against the master repository, or I can plug the thumb drive into > the embedded system and do pulls/pushes from the local embedded system with > the repository on the thumb drive acting as the remote master. > > If I "cd" to the thumb drive repository and run git push (which I thought > would push my changes to the master repository) I get the following error: > > $ git push > To /path/myrepo.git/ > ! [rejected]master -> master (non-fast-forward) > Any suggestions? Having more than one bare repo probably won't work well. I would put a repository with working directory on the thumb drive. Now you can't push to this repo anymore, but you don't have to. Simply pull the changes from your embedded device to the thumb drive. Then you can push them to the master on your PC. Similarily you can pull changes from your master to the thumb drive and then pull the changes from the thumb to your embedded device. In other words, simply replace the embedded -> thumb push by a thumb <- embedded pull. Also remember that a git pull is just a git fetch followed by a git merge. Might help with the bare repo. Stefan signature.asc Description: This is a digitally signed message part. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata trouble
On Sunday 23 September 2012 10:19:52 Alan Teeder wrote: > The reason I quoted 10 Gb is that my fgdate/.git/objects directory is > currently 8.9Gb, and I assumed that is what gets downloaded during a clone. > I bow to your wisdom if you say that it is "only" 4.9Gb. Since really only the initial clone is a problem, we could just offer a weekly updated tar ball of a bare clone for download. This download would just be ~ 5 GiB and would be resumable. Getting an up to date fgdata for the first time would then just be something like the following sequence: wget -c http://.../fgdata.git.tar.xz tar xJf fgdata.git.tar.xz cd fgdata git checkout master git pull This would keep all the advantages of having everything in the same repo while offering a reliable solution for people who download for the first time. Keeping the tar ball up to date would be a simple cron job. Any thoughts? Stefan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Usability
On Sunday 12 August 2012 16:07:18 Martin Spott wrote: > Whereas there's little use of TerraSync without the FG flight sim, > there are plausible usage scenarios for FGCom _without_ FlightGear, > let's say for ATC. Therefore, while it makes sense to package FGCom > alongside with FlightGear for the releases, I'm having mixed feelings > about incorporating FGCom into FlightGear core because this would > either: > a) require to bear all the ballast of FG even if the only thing you'd >like to have is FGCom, if FGCom development moves into FG or > b) carry the risk of FGCom-in-FG diverge from standalone FGCom. But it's not an either/or. There could be an FGCom binary that uses the same code as the built-in FGCom. Stefan -- 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 licence for 2.8 and later
On Thursday 05 July 2012 07:50:20 Michael wrote: > Everything on GPL only means: > - less scenery and airplanes included ( wasn't there recently some > photoscenery rejected because of the GPL?) There are already 565 airplanes to choose from in git (all licensed GPL). More than enough for me, if you ask. > - authors lose copyrights You obviously don't know anything about copyright law. > - only to find their work rebranded and sold for ex. as flightprosim etc. So instead, you want to have countless unusable models because their authors lost interest and they are no more compatible with the current FlightGear version and nobody being able to fix this because the license doens't permit? How exactly would this be better than having 565 airplanes already with more coming all the time? > Having only the code on GPL and everything else as freeware...seems less > narrow minded to me. All advanced airplane models contain code (Nasal). So you're arguing for using GPL for models as well. Ok. Stefan -- 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] Release 2.8.0: feature freeze starts now
On Sunday 01 July 2012 15:47:11 ThorstenB wrote: > Yes, building inside the source tree has all kinds of pitfalls. And due > to the ".gitignore" files which are there to ignore all generated files > (and keep them from being accidentally committed to git), it's almost > impossible to tell whether a source tree is still fresh & clean or > somehow tinted by a previous build. But there's still git clean -fdx which deletes all files and directories unknown to git ignoring the .gitignore file. In other words, it produces the same result as a completely fresh git clone. Another way to get the same result is to git clone from the local repository. The remote for tracking upstream can be added to the config later on. Stefan -- 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] Nasal performance
On Tuesday 22 May 2012 13:04:24 Andy Ross wrote: > On 05/20/2012 11:37 AM, Stefan Seifert wrote: > > Generational garbage collection is not that difficult. When you have a > > working mark& sweep GC, extending it to be generational is rather > > straight forward and can greatly reduce GC runtime > > Runtime, yes, but not latency bounds. You still have to touch the > whole heap eventually. > > But you're right: allocating objects into generations and only > mark/reaping from the most recent one on most iterations is a > straightforward optimization and will definitely make things faster. Maybe even simpler: run the GC in a separate thread. Threaded GC usually is quite tricky but in this case it may not be that much of a problem. Is there any time during processing a new frame when no Nasal is run but something else which is time consuming? This could be the perfect point to hide the GC's latency. FG does not use multiple cores that well so there should be at least one core which is bored and might tend to the garbage instead while the main thread is busy rendering pretty graphics. A single condition var might be enough to ensure that the GC is not running at the same time as Nasal execution. In my naive imagingation, this sounds like a single evening experiment ;) Stefan -- 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] Nasal performance
On Sunday 20 May 2012 16:59:40 Vivian Meazza wrote: > Andy also says of GC: > > "Fancy items like generational collectors fail the "small and simple" > criteria and are not likely to be included." Generational garbage collection is not that difficult. When you have a working mark & sweep GC, extending it to be generational is rather straight forward and can greatly reduce GC runtime. Most of all you wouldn't have to care about long lived objects like code itself anymore, since it's only for the first couple of runs where it gets marked. Adding generations to the GC is probably one of the simplest ways to improve FGs performance. Stefan -- 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] Water shader issues
On Sunday 22 April 2012 14:46:09 Bertrand Coconnier wrote: > And if, at the end of the day, your > change is not included in FG, will it be that terrible ? As a user, I would answer this with yes. Water looks fantastic in FG but it's also taking quite some toll in performance. Since performance is the main limiting factor of having fun with FG for me (usually having 10-20 fps), changes like this can make the difference between having a flat and boring blue surface and the beatuiful sea like I have seen it from an actual airplane. Stefan signature.asc Description: This is a digitally signed message part. -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Water shader issues
On Monday 23 April 2012 07:05:58 Renk Thorsten wrote: > See above. All I can say is that I am really, genuinely frustrated with the > way this is going, and so I will simply put the matter to rest, restrict > myself to making my own set of shaders faster and just shut up. Please don't. Framerate is all that keeps me from having fun with FlightGear. Stefan signature.asc Description: This is a digitally signed message part. -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Willfully violating Google Terms of Use
On Monday 12 March 2012 11:17:05 Martin Spott wrote: > No, not by "looking" at a map, but by "buying" a printed map - which is > what I stated above. Since you hardly get your hands onto commercial, > printed maps (which I believe is the item we're talking about) without > the act of buying the media, the act of purchase and thus signing the > contract is implicit by looking at the map at least in most of > the cases. > > Well, you can always argue "oh, I didn't buy this map myself, I just > found it on the road after someone dropped it there". Anyhow, most > maps I know are having their origin and the Terms of Use printed > somewhere in the legend or on the back and I suspect you'll face hard > times arguing that, by accident, you didn't notice these terms before > starting to derive measurements from the media - especially when > you're tring to explain that you found dozends of maps on the road :-) Like everything in law it's rather more complicated than one would expect. For example at least in Germany and Austria but problably most of Europe, these "Terms of Use" printed on the map are no more legally binding than an "End User License Agreement" which many programs display on first start. That is because in these jurisdictions, one cannot change a contract after the fact. So to be legally binding these terms of use would have to be part of the buying contract and the buyer would have to be able to read them and agree to them before buying for the terms to be legally binding. Just print them somewhere on the back of the map is simply waste of ink. I guess the moral of the story is that one should not try to determine legality by oneself, but ask a lawyer. Which is kind of ironic, since these laws are all binding for us, but the way it is is the way it is. Stefan signature.asc Description: This is a digitally signed message part. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Double Input Resolution?
On Friday 09 March 2012 13:27:19 Eric van den Berg wrote: > Agreed, but the as you are saying, the brake is hydraulic and therefore > there will always be a valve that traps the hydraulic fluid and keeps the > pressure on the brake pistons. This valve will always only be fully closed > in the end position (Just as a tip if you will be using a 'double'). This > is standard on _most_ small aircraft as there is only one predominant > supplier for wheels and brakes for small aircraft. The implementation may > be different, the equipment is the same on every single aircraft. Most gliders I've flown do not even use hydraulics for brakes. And the parking brake often is nothing more than some hook or lever which can be used to lock the brake lever. But it's still a 0 or 1 thing. The brakes either are locked or not. Of course, full brake may still not be enough to keep the aircraft in place or not even to prevent it from taking off... Stefan -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
On Sunday 04 March 2012 17:30:41 Christian Schmitt wrote: > Curtis Olson wrote: > > I have a local branch I've created here for some experimentation. When > > ever I do a git pull from the gitorious repository, I do that in the > > "next/master" branches. Then I switch to my local branch and type "git > > merge next (or master)" to make my local branch up to date with the main > > development "head". > > > > There may be a better way to do that, but it's what was suggested to me, > > and seems to work and I've stuck with it. > > For the sake of completeness and (possibly) nicer git history in the future > let me say this: > > There IS indeed a better way for exactly your use-case: > When switching back to your local branch after "git pull" in next, use "git > rebase next (or master)" on your local branch. This makes sure your changes > are always on top of your local branch and prevents those "Merge commit XXX" > messages in the git history. But whenever talking about git rebase one should mention that THOU SHALT NOT rebase a branch which you've ever pushed. Because if someone ever pulled your branch (which happens with a simple git pull from the main repo), his get gets confused by the changed history. Stefan -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Re : Looking at a nice project from
On Saturday 25 February 2012 11:21:03 Martin Spott wrote: > Thus you never know wether your job > is going to take just a few days, a few weeks or a few months. > I don't like jobs running several months. I had a few of these but the > most promising ones were killed when the machine had to be rebooted due > to a planned power outage - or an unplanned power outage - or some > other reason. Just wanted to let you know: I've got a server with an i7, 8GB of RAM and a couple of 100 GB free space sitting in Hetzner's data center very idle day and night. The things I use it for could probably run on my wireless router. So if you need a machine which runs very stable for months at a time, just tell me. I'd love to put this thing to better use and could give you full shell access. Stefan -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] new fedora
On Saturday 14 January 2012 00:20:33 Peter Sadrozinski wrote: > Hello, > > I'm hitting an 'interesting' problem with the new fedora. For some reason, > it's installing the PAE kernel (I guess I should have installed the 64 bit > version). The problem is, when the system() is called - for instance, to > copy an airport btg file from work to output, I get an error. > > Here's debug from copying of said airport: > > running cp ./work/AirportObj/w090n30/w085n33/KATL.btg.gz > ./output/w090n30/w085n33 > system: : Cannot allocate memory > returned -1 > > I'm not buying the out of memory error. Please beware that while PAE allows a 32 Bit OS to use more than 4GB of RAM, it does not change an individual processes limit. Maybe this is what bites you here? Stefan -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ccmake problems with flightgear git latest
On Wednesday 11 January 2012 13:27:04 Viktor Radnai wrote: > I had the same issue. It's quite odd. Git status was showing my tree as > unmodified but I had to do the same thing (clone a new copy) with > simgear otherwise it was not finding OSG in /usr/include. I think it was > only looking in /usr/local/include for some reason. If git status showed nothing, there could still be generated files covered by .gitignore which had to be cleared like some cmake cache. You can see them with git status --ignored To bring back your working directory to the pristine state in the repository, you can use git clean which removes all files that git doesn't know about. git clean -x would clean even those which mach rules in .gitignore > On 12/06/2011 12:51 AM, Sid Boyce wrote: > > A new clone of flightgear sorted that problem out. > > Regards > > Sid. > > > > On 05/12/11 23:38, Sid Boyce wrote: > >> [ FindOpenSceneGraph.cmake:130 ] Failed to parse version number, > >> > >> please report this as a bug > >> > >> CMake Error at > >> /usr/share/cmake/Modules/FindOpenSceneGraph.cmake:199 > >> > >> (message): > >> ERROR: Version 3.0.0 or higher of the OSG is required. > >> Version .. > >> > >> was > >> > >> found. > >> > >> Call Stack (most recent call first): > >> CMakeLists.txt:194 (find_package) > >> > >> # rpm -q OpenSceneGraph > >> OpenSceneGraph-3.0.1-55.x86_64 > >> > >> I had the same problems with simgear until I did the latest git pull. > >> openSUSE cmake-2.8.6-3.4.x86_64 -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Interesting read on hosting huge git repos
FG seems not to be the only project which has problems with multi GB git repos. The Linux kernel and Android are in the same league and they have experiences of their own. This might be an interesting read: https://plus.google.com/112413860260589530492/posts/EJCsVq6o1vF Stefan -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees & buildings
On Thursday 29 December 2011 10:21:11 Vivian Meazza wrote: > That said - why use drivers that cannot handle .dds compression formats? I > assume closed source drivers are OK? They simply are not. I currently cannot use FlightGear due to simply unusable performance with free drivers but still, it's worth this tradeoff for me after years of pain with closed source drivers (both NVidia and ATI/AMD). Free drivers allow me to: * do my job which is programming which needs loads of text on the screen (closed source drivers gave unusably low performance here) * have multiple X servers running, so my girlfriend can have her own user on my computer without either of us having to log out all the time * upgrade to current (development) kernel any time * have decent video performance * actually get support for kernel problems In sum, these features are worth more to me than FlightGear, though I miss it very much. The free radeon drivers nowadays are good enough for many games and other software. It would be nice if FG developers acknowledged their existence and avoided breaking their user's experience. Personally I hope to get back to at least flyable performance levels with a CPU upgrade in the near future. But even if not, I would never go back to closed source drivers. Stefan -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: git question
On Tuesday 13 December 2011 13:19:25 Curtis Olson wrote: > I have a local project here that uses git and has a single master branch. > > I had a wild and crazy idea that I wanted to explore, but knew it would > involve a lot of code refactoring and rearchitecting -- I didn't want to > mess up my good working tree -- especially if the idea didn't work out. So > I created a branch: > > git checkout -b newidea > > I then pushed forward with the new idea inside this branch, made several > rounds of changes and many commits to this new branch. Now I really like > my new idea and I want all this work moved back into my master branch. > > What's the best way do to this? You want to merge your branch back into master. merge is the right word: git checkout master git merge newidea done. If the merge creates conflicts, git will tell you so. To fix them, simply edit the files and add them to the index (git add fixed_file) and when you are done do a git commit. A merge usually creates a new commit anyway, since it's a new version of your source tree. > Could I rename the master branch to be "pre-newidea" or whatever I want to > call it, and then rename my "newidea" branch to "master"? Or is that bad > git practice? Would be possible as well, but branching and merging are the basic tools in git and they are fast, simple and work quite well. And they create no confusion if someone else got your old master branch. Stefan -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ridge lift seems broken
On Wednesday 03 August 2011 11:44:23 thorsten.i.r...@jyu.fi wrote: > It's quite possible that it's broken for a while - there are not so many > glider enthusiasts around, But they do exist :) But I only tried it once in FG, since performance with the free radeon drivers is just barely usable. But I'll definitely give it another try soon. Stefan -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Improved forests
On Thursday 28 July 2011 06:22:10 Gene Buckle wrote: > On Thu, 28 Jul 2011, Jari Häkkinen wrote: > >>> Are you sure about that? I just tried it with a little example and > >>> at least gcc compiles both variants to the exact same assembly > >>> code. Tried it with and without -O2. > >> > >> That would freak me out. Doesn't "++j" mean "increment j, then test" > >> whereas "j++" means "test j, then increment"? > > > > No, for a for loop > > > > for ( [1]; [2]; [3] ) > > > > where [3] is ++j will increment j before use. However, in an > > if-statement the complete statement [3] is evaluated before the test [2] > > is done. If the compiler is smart it will produce the fastest binary > > code regardless ++j or j++. However, if the [3] is more complicated like > > a hypothetical i = ++j + k the compiler will most probably generate > > different binary code (compared to i = ++j + k). > > Right, but j++ will increment _after_ it's used, correct? So how could > ++j vs j++ generate the same assembly code and be correct? Because the for loop is a case where it simply doesn't matter. Translate the for to a while: int i = 0; while (i < 10) i++; is just the same as: int i = 0; while (i < 10) ++i; because the value of the incrementing expression is not used anywhere. The compiler recognizes this as one of the simplest cases of optimization. Stefan -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Improved forests
On Thursday 28 July 2011 01:00:10 Hal V. Engel wrote: > But there is one minor and very common issue with the code that should be > fixed. In the for loop > > for (..; ..; j++) > > should be > > for (..; ..; ++j) > > if you use j++ the compiler has to make a copy of j with each iteration of > the loop but if you use ++j it does not have to make a copy. This will > make the loop more efficient although only by a small amount. Are you sure about that? I just tried it with a little example and at least gcc compiles both variants to the exact same assembly code. Tried it with and without -O2. Regards, Stefan -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] "Pro Flight Simulator"
On Wednesday 08 June 2011 12:27:30 Arnt Karlsen wrote: > On Wed, 8 Jun 2011 12:06:48 +0300 (EEST), thorsten.i.r...@jyu.fi wrote > in message > > > Correct me if I'm wrong, but I can't see how willingness to exercise > > copyright under GPL would require moving to a different license. > > ..you assume such "moving moving to a different license" has not taken > place, (y)our (f)actual unwillingness to actually exercise your rights > under copyright law to defend or enforce your copyrights, can be > construed and asserted as "a new license" alongside the GPL. May I ask on which jurisdiction your claim is based? Because I know for a fact that it does not have anything to do with German or Austrian law and am quite sure that there is no other European country where the law works anything like you described and the same goes for the USA. Could it be that you're mixing copyright and trademarks? Because trademarks are the only kind of "intellectual property" rights which you have actually have to enforce in order to not lose them. There's no such need for copyright or creator's rights. For the latter, one cannot even lose them if one wants. They are non-transferable and non- relinquishable. Stefan -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] "Pro Flight Simulator"
On Wednesday 08 June 2011 07:43:12 Michael Sgier wrote: > why not simply change the fgfs licence once and for all? Android is not all > GPL anymore...we could do the very same.- Would you really want to restrict the very freedoms that made FlightGear such a successful project, just to have some legal means against some shady people who try to fool the uninformed into paying some money for FG? Chances are, that a different license would not even help, since you couldn't even find out who to sue. I do not have much code in FG, but I for one would absolutely oppose such a useless and destructive move. If not for the freedom, I would never have bothered with FG. I would just have payed a couple of bucks for X- Plane and be flying. Yes, it leaves a very sour taste that people who have contributed nothing are earning money (we don't know how well they do btw.) while the people who did the work get nothing. But the truth is that we wouldn't get anything in any case and we chose it that way. People are cheated every day and thiefs get loads of money. It's sad, but nothing will change that. If you really want to fight those scamers, there's a very simple way to do that: inform people. Marketing. People who know about FlightGear will not pay for an outdated copy. Go out and write about FG in aviation forums and blogs. Write letters to aviation magazines which include articles about flight sims. Write about FG in all the social media you use. Post loads of cool videos on Youtube. Be visible! Everyone can help here and it takes only minutes for every action. This helps not only preventing people from getting fooled, but also to get more users and hopefully contributers which is a hell of a lot better than having to deal with law suits, distracting developers and reducing freedom. I say let's change the fight into one they simply cannot win. That way we will not only stop losing something, but actively win visibility, users and contributers. Stefan -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gnome 3 ?
On Friday 03 June 2011 06:10:24 Curtis Olson wrote: > Looks like the linux desktop folks have stopped chasing windows and are now > chasing mac? Quote from an online review: gnome 3 gives you any color > theme you like ... if you like black. s/linux desktop/Gnome/ There's still KDE and all the lighter desktops available which do not force anything on you. And according to a phoronix comparison, the KDE window manager seems most of the time to be the one affecting performance the least. And if that's still too much, deactivating desktop effects is just a shortcut away. http://www.phoronix.com/scan.php?page=article&item=linux_desktop_managers1&num=1 Stefan -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Segfault with OSG multi threading
On Tuesday 31 May 2011 14:17:23 Mathias Fröhlich wrote: > So, what to do: > > The real solution is hard. Tim effecs code *probably* shows how to solve > this. I have never double checked if this is done in a waterproof way, but > I would guess this is ... > > A solution that might at least work for most configurations could be like > this: Make sure the splash screen draw already asks for a bunch of > extensions in the osg way. Then make sure we do not need the decision > before the spash screen is there. Tehn finally use the osg extension query > functions with an appropriate second argument to make sure the cached > result is taken for this mentioned static initialization time usage in the > sky code. > > Hope this helps a little ... First: thanks to you, Thorsten and Anders for your help. I tried just commenting out the extension checks and indeed, FG starts and is using two threads which for the first time since I switched to using the free radeon driver gave me somewhat usable framerates up to 15fps :) Next I will try your suggestion using OSGs caching. Seems like the least intrusive way to get this working with enabled checks. Stefan -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Segfault with OSG multi threading
On Friday 13 May 2011 11:03:24 Anders Gidenstam wrote: > Presumably it will also increase the risk of triggering any race condition > and/or unsynchronized data access bugs that may be lurking in the code. > There are some known ones (e.g. during the creation of a particle > system) but there could easily be more. > > In this case you should investigate the arguments and locals in the > different stack frames to see if you can see something looking bad. Stack looks quite fine and it does not feel like a race condition to me. It's 100% reproducable and always in the same place and adding a sleep here and there does not change anything. Well everything looks fine except for the big picture. There are two threads running. One running OSG rendering stuff and the other FG's main loop. The segfault happens when the main loop thread tries to access GL information. I know next to nothing about openGL programming but I seem to recall that it's not allowed to access the same GL context in different threads. So how is this supposed to work? (gdb) thread apply all bt Thread 2 (Thread 0x7fffec712700 (LWP 15449)): #0 0x77bcd38c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x73a4021d in OpenThreads::Condition::wait(OpenThreads::Mutex*) () from /usr/local/lib64/libOpenThreads.so.12 #2 0x74dc2d3b in osgViewer::Renderer::ThreadSafeQueue::takeFront() () from /usr/local/lib64/libosgViewer.so.76 #3 0x74dc3506 in osgViewer::Renderer::draw() () from /usr/local/lib64/libosgViewer.so.76 #4 0x73de291e in osg::GraphicsContext::runOperations() () from /usr/local/lib64/libosg.so.76 #5 0x73e3693a in osg::OperationThread::run() () from /usr/local/lib64/libosg.so.76 #6 0x73de4a88 in osg::GraphicsThread::run() () from /usr/local/lib64/libosg.so.76 #7 0x73a3fd90 in OpenThreads::ThreadPrivateActions::StartThread(void*) () from /usr/local/lib64/libOpenThreads.so.12 #8 0x77bc8a3f in start_thread () from /lib64/libpthread.so.0 #9 0x7328267d in clone () from /lib64/libc.so.6 #10 0x in ?? () Thread 1 (Thread 0x77fa7760 (LWP 15446)): #0 glGetString () at glapi_x86-64.S:9877 #1 0x00abe70a in SGIsOpenGLExtensionSupported (extName=0xbe7cda "GL_ARB_texture_env_combine") at extensions.cxx:64 #2 0x009687cc in SGCloudLayer::rebuild (this=0x7fffe31785b0) at cloud.cxx:389 #3 0x00967d0b in SGCloudLayer::SGCloudLayer (this=0x7fffe31785b0, tex_path=...) at cloud.cxx:210 #4 0x004357c4 in fgIdleFunction () at main.cxx:424 #5 0x004a1d8e in fgOSMainLoop () at fg_os_osgviewer.cxx:284 #6 0x00436903 in fgMainInit (argc=1, argv=0x7fffdbd8) at main.cxx:659 #7 0x00433899 in main (argc=1, argv=0x7fffdbd8) at bootstrap.cxx:243 Cheers, Stefan -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Segfault with OSG multi threading
Hi! While trying to get some double digit frame rates out of FG next, I tried to enable OSG multi threading in preferences.xml, but that leads to a segfault: #0 0x772af357 in glGetString () from /usr/lib64/libGL.so.1 #1 0x00ab9b3a in SGIsOpenGLExtensionSupported (extName=0xbe075a "GL_ARB_texture_env_combine") at extensions.cxx:64 #2 0x0096501c in SGCloudLayer::rebuild (this=0xcabfa90) at cloud.cxx:389 #3 0x0096455b in SGCloudLayer::SGCloudLayer (this=0xcabfa90, tex_path=...) at cloud.cxx:210 #4 0x00435430 in fgIdleFunction () at main.cxx:429 #5 0x004a16f6 in fgOSMainLoop () at fg_os_osgviewer.cxx:284 #6 0x00436535 in fgMainInit (argc=1, argv=0x7fffdbc8) at main.cxx:662 #7 0x00433519 in main (argc=1, argv=0x7fffdbc8) at bootstrap.cxx:243 multithreading-mode is disabled by default with a note, that it breaks screenshots. Is this the only reason or is it known not to be stable? Thanks, Stefan -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
On Wednesday 26 January 2011 01:34:35 Curtis Olson wrote: > The other implication here is that it would be extremely handy to have > multiple branches checked out simultaneously for other reasons. git makes > branching easy, yes, but if you find yourself bouncing between branches > with changes for separate projects, and external events may require you to > jump to a different branch at a moments notice, It's a major PITA to have > to commit every little thing you are in the middle of to switch to another > branch. Well you don't. Often you just can leave modified files in place while switching branches. If it's not working, you still can simply git stash before switching. git stash creates a temporary branch and commits your local changes to that branch. git stash apply lets you get back those changes, even if you're on a different branch than before (it's just like a git merge stash). I found the book "Version control with git" quite useful. Yes it's somehow strange to need a book for a simple tool like a VCS, but git's features are IMHO worth having to read a little. Stefan -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New release
On Thursday 23 December 2010 21:12:16 John Denker wrote: > > Maybe if you have a text-to-speech system set up it works properly, > > but I assume most people downloading the new release will not have > > that setup by default. > > Agreed. Getting TTS to work "live" (as opposed to batch) is way more > trouble than ordinary users are willing to put up with. Makes me wonder how difficult it would be to fully integrate festival into FlightGear. Not using some external program, but linking the library and shipping appropriate voice files. Stefan -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ridding Multiplayer of Abusers
On Wednesday 20 October 2010 18:57:05 Nathanael Rebsch wrote: > Implementing such a filter on the client side will open your eyes to the > pitfalls of that quite quickly - i'll just compile fg myself, and apply > a patch which disables such a filter - now what you want to do? > > security by (client side) obscurity can be quite nice, but i really > think at some point this has reached its limits. If the filter is on the receiving end it doesn't matter. When someone wants to see all bad words, he may remove the filter. Anyway it would only affect himself. Stefan -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ridding Multiplayer of Abusers
On Tuesday 19 October 2010 18:51:37 Martin Spott wrote: > Stefan Seifert wrote: > > Very sensible words. Technical solutions usually don't work for social > > problems. > > Exactly this is the point, and I'd like to add that the social problem > we're currently looking at might be manifold But I'd also like to add, that Curt's idea of simply logging multiplayer chat messages might help creating the social pressure to behave decently. As people already don't know, who might be listening on a frequency, privacy should not be an issue. If some people need real privacy, they should already use a private server. Stefan -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ridding Multiplayer of Abusers
On Tuesday 19 October 2010 16:41:35 Mally wrote: > ?Forgive my ignorance, but what happens at the moment? Does nobody say > anything to the abusers? Doesn't peer pressure, good example and setting > guidelines present a more realistic solution (realistic by comparison with > what happens in real world aviation I mean) rather than coming up with an > automated system of blocking and control? Very sensible words. Technical solutions usually don't work for social problems. A simple word filter would not prevent me from offending people or even expressing death threats. It would probably not even prevent me from swearing excessively in German. It might on the other hand prevent me from simply talking to people. As an example: "jap" may be an offending reference to a Japanese (as on Curt's word list), but also simply be the German form of "yep". A word I use daily. Social problems are best solved by social solutions. In a friendly, welcoming and helping society foul language and threats usually don't come that far. For death threats, there are even more severe means available. Those are illegal in pretty much any country I know of and would result in immediate prison to protect the victim. The state simply cannot be sure if the offender might really do it. Stefan -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] buying server bandwidth (was: mpserver02 close down)
On Thursday 07 October 2010 17:38:13 Curtis Olson wrote: > I haven't researched this, but I wonder what a fair price would be to rent > a dedicated linux server with an unmetered 100mbit connection to the > internet? Would that be sufficient to run a good multiplayer server? One company that I can certainly recommend is Hetzner in Germany (www.hetzner.de). I pay 49 Euros per month for a root server with a Core i7-920, 8GB RAM and 2x750GB HDD. 100MBit/s connection with unlimited traffic. Unlimited meaning 5TB/month after which speed gets reduced to 10MBit/s. They also have smaller offers like an entry server at 29 Euros per month for which you get an Athlon 64, 1GB RAM, and 2 TB traffic. No, I do not work for them, but I'm a very satisfied customer who hasn't found nearly bang for the buck and quality anywhere else :) But if someone can correct me, I'd be grateful. Stefan -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup problem
On Sunday 25 July 2010 18:38:45 fiers...@zonnet.nl wrote: > I second that. As the matter of fact I stick to nVidea for all machines > over the years, because I feel that nVidea should be rewarded for their > support of Linux and ATI should be punished for not taking Linux seriously. On the other hand, I'm running a system with 100% free software thanks to AMD's releasing of documentation for driver writers for ATI cards. And my ATI card with its free drivers allowed me for the first time in many years not only to run FlightGear but also good video performance, desktop effects in KDE and usable performance with anti aliased fonts which is something NVidia never managed to do for me (some known problems with their drivers which never got fixed). Times change. Stefan -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
On Tuesday 06 July 2010 16:15:36 Martin Spott wrote: > Even though a 2.8 GHz Socket 940 Opteron is by far not state of the art > in these days, I think this scenario is a sufficient proof that the > statement "FG itself isn't CPU limited" doesn't hold. As are the 100%. If the application is bound by the graphics card's performance, the CPU cannot reach 100% utilization, since it would wait for the graphics card to finish drawing. 100% CPU load show, that the graphics card can execute drawing instructions faster than the CPU can generate them. Thus the application is CPU limited. Stefan -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear git repositories (was Re: GIT or CVS - Confusion)
On Saturday 22 May 2010 15:16:41 Jonathan Wagner wrote: > What about "git clone --no-checkout" in the data directory? This should > create/pull the .git folder with all of the VCS information, but not > actually download any files. After that completes, try running git status > to see if only changes since your CVS update are out of date or if the > whole repository wants to be checked out. I don't think that changes anything, since the .git folder contains all the data of all revisions anyway (compressed) and I cannot imagine that a git clone does actually transfer more than that. I just checked fg-data out and it transfered about 2.16GiB of data. If it helps, I could put that in a .tar.lzma on my webserver and you could download as much as you can afford this month and the rest next month. Just tell me if you want. Stefan -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Web Site
On Tuesday 23 March 2010 07:08:47 Michael Sgier wrote: > Yea not bad but still a little low-tech. What about such: > > http://www.activision.com/index.html#home|de_DE > > Click on images either for links for screenshots. Interesting also for the > future when we hopefully have addons. So you could get an impression and > then decide to visit the link or not. Yeah great. It just takes about half a minute to load the page and then still have no usability at all. Stefan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Github and aircraft
On Sunday 21 March 2010 11:50:01 Alexander Barrett wrote: > Sounds very interesting, I've had a look at GitHub and I've a few > questions, if you don't mind answering (purely as I don't know anyone else > with experience of it) Is there any support for media files, such as > Sounds/Images with version control or is it just text/code based? Also can > you do offline editing or is it all online via their own editors? git supports binary files just fine. As github ist just hosting for a central repository, all editing is done offline anyway just like with the current CVS. Stefan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate files in base package
On Friday 26 February 2010 17:16:38 Detlef Faber wrote: > I guess most duplicate files are instruments which are not in the > generic folder. > Of course it would be desireable to have them all in one place and > reference to there, but that would cause severe problems with the > aircraft downloads, because every aircraft on the download page would > need a second package for instruments which are not in the Base > package. > Including all these Instruments in the Base Package would greatly > increase the download size. This repeatedly strikes me as problems that Linux packages managers have solved completely, elegantly and simply a long time ago. They support dependencies, so commonly used parts only have to be installed once. They support versioning, making upgrades simple and safe by for example not allowing binaries to be installed alongside incompatible data. With systems like the openSUSE build service, users can even create their own repositories and link to others. Those systems even support mirrors to spread downloads. Maybe it's time to use what's already there? Stefan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An important message for mirror maintainers
On Wednesday 24 February 2010 17:34:19 Brant Gipson wrote: > Torrent will not work as well as FTP or rsync mirrors. You have to > update the .torrent files. I'm not sure how that works though. But torrents can be a great addition. I usually download new openSUSE releases much quicker using the torrent and continue to seed for quite some time. It's a very useful technology. Stefan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed new set of splash screens
On Friday 19 February 2010 09:48:51 Erik Hofman wrote: > I've created a new set of splash screens based on the images Durk > created about two weeks ago. > Does anyone have any objections to committing them or does anybody have > other possible splash screens to choose from? Well to state the obvious: they look very good! But the term "freeware" will most probably raise objections. Freeware means free of cost but otherwise restrictions may apply while FlightGear is really free software with much more user rights. So maybe you should change that to Free Flight Simulator? Stefan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
On Saturday 06 February 2010 21:29:23 Csaba Halász wrote: > Well, I still think the sensible thing is to expect *native* libraries > in /lib, whatever native may be. If you are on 64 bit, that means 64 > bit libraries go into /lib and not /lib64. The only situation I would > expect /lib64 is if I am on a 32 bit system. If I am sitting on a 64 > bit machine and I need 32 bit libraries, I put the 32 bit libraries > elsewhere separated from my native libs (which is what debian does - > you get /lib32). On x86_64, _both_ 32 and 64 bit are native. So it's a pretty arbitrary choice, which libraries you put in lib and if you have an accompanying lib32 or lib64 directory. openSUSE for example puts 32 bit libs in lib and has lib64 directories which has the nice advantage, that there has never been a compatibility problem. Running 32 bit Java/Flash/wine/... on an otherwise 64 bit system is a non-issue. No chroot or workarounds like that needed. I only could wonder when I read about problems, why distributions would do that to their users... Stefan -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Money and Contributions
On Sunday 31 January 2010 12:40:54 Durk Talsma wrote: > I remember being involved in the discussions. I've also been thinking about > the possibilities of setting up a non-profit organization for the support > of various aspects of FlightGear. I wonder if some existing organization may fit that role already. Maybe as an example the Free Software Foundation could handle those things. They work for free software, are arguably trustworthy, have branches all over the world and loads of experience in such matter. I don't know if they would help, if we want to trust them and if it's at all possible, but it may at least be worth a thought or two. Stefan -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GUI dialogs suck
On Friday 29 January 2010 10:27:24 Erik Hofman wrote: > Like your comments indeed. > If it really sucked then others would have complained already, and most > likely it would have been fixed by now. Please don't take offense by his offensive choice of words and do not dismiss his valid points because of that: compared with what I'm used to on my KDE desktop the widgets in FlightGear really are very basic and I've experienced the same frustration as Pete did. If it were possible to switch to Qt for widgets that would be a massive improvement in my eyes. We would go from "most basics work" to "top of the line". The question is: is it even possible to use Qt widgets in a GL application? The next one most probably: would there be any drawbacks? Stefan -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Please remove 727-230 from CVS- Licence issues!
On Saturday 23 January 2010 10:43:13 Erik Hofman wrote: > Erik Hofman wrote: > > Or maybe it's good enough to replace the texutures with plain white > > images for now? > > I've done this until an agreement is reached. I hate to be the messenger here, but I think it's really obvious that these textures have to be removed from CVS completely including any history. Because otherwise one could just checkout an older version of the textures to get them thus we would be distributing them, which is explicitly not allowed by the CG textures license. Stefan -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Copyrights
On Tuesday 05 January 2010 01:10:33 J. Holden wrote: > unless the contributors agree to assign their copyright to an entity > (FlightGear). And who would this "FlightGear" be? Stefan -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
On Monday 14 December 2009 05:46:11 Chris Wilkinson wrote: > There could have been any number of better ways to express the version > number, but they chose to use one that can combine more than one decimal > place into what looks to a lay person like a mistyped number... not > clever. Well they chose major and minor version numbers delimited by a dot, which can and is easily extended to even finer granularity by just adding another group or two. It's certainly no perfect system, but it's been adopted in practically the whole computer industry, software and hardware. So FlightGear is in fairly good company there. The chances that someone would misunderstand this universally adopted scheme are quite small if you ask me. People seem to cope with it quite well, as they do with IPv4 addresses which are usually written as four groups of numbers seperated by the same dot: 123.45.67.089 And anyway: here in Europe (except for the UK and Ireland), we don't even use a dot as decimal separator. We use the comma while the dot is used for grouping thousands. And it's the same in many other parts of the world, for example South America. So what's wrong again with using the same system that just about everyone else uses? Stefan -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] (no subject)
On Wednesday 18 November 2009 13:41:32 cullam Bruce-Lockhart wrote: > In the case of the stuff > I'm doing, the elevation model is very detailed, and the surfaces beyond > 45 degrees can't realistically support trees. That's wrong: they can and they do. Have you ever been in the Alps? I've often been amazed at in which unlikely places plants still grow happily. Stefan signature.asc Description: This is a digitally signed message part. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear in industry use
On Wednesday, 28. October 2009, Maik Justus wrote: > Arnt Karlsen schrieb am 28.10.2009 17:26: > > ..aye. One problem, they provide FG binaries, but no source??? > > http://www.cloudcaptech.com/download/Piccolo/FlightGear/ > > Do they have to provide the source to everyone? Or do they just need to > "deliver" the license within the download and provide the source to > everyone who asks for it (or, if they didn't altered the source: a link > to http://www.flightgear.org/Downloads/source.shtml ) This whole discussion about the GPL and people/companies redistributing FG seems to be based on a very wrong assumption: that we have to figure it out completely on our selfs. People, there is the GPL FAQ, which is very easy to read. There's the Free Software Foundation which is quite passionate about defending free software like FlightGear. There's the Software Freedom Law Center which provides services free of charge to free software projects and gives for example "License Defense and Litigation Support". Yes, that means that there actually are free lawyers available for projects like FlightGear. Why not use them instead of guessing on our own what and how to do? With regard to the question about the GPL: http://www.gnu.org/licenses/gpl-faq.html#DistributeWithSourceOnInternet Cheers, Stefan -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Photorealistic textures for cumulus clouds
On Wednesday, 28. October 2009, Heiko Schulz wrote: > Some pics which shows that with this clouds we are really close to or even > took over the Qualitity of MSFS and X-Plane: just some contrast fixing and > white balance and the black stripes added. I sent to a swiss flight > simulation forum, I wait for answers Holy cow! I doubted that this was FlightGear till I looked at the ground textures. Just great work! Can't wait till I get usable graphics drivers again so I can try this out. We're definitely getting better in the eye candy department. Cheers, Stefan -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
On Tuesday, 29. September 2009, Olaf Flebbe wrote: > Let me talk from the Windows perspective: > > git seems to work best with msysgit. Entrance barrier: You need to know > UNIX shell. (After trying out I would recommend the msysgit rather the > cygwin). Documentation of msysgit is almost non existing and sometimes > misleading. But: It works. Has anyone ever tried TortoiseGit? http://code.google.com/p/tortoisegit/ Seems to be a nice and working git client for Windows and I can't remember it being mentioned on this list. > svn implements push. hg can implement both. git seems more designed for > pull (linux kernel process), but can implement push too (samba git for > instance, mapserv?). I've only ever used git in push style so I can confirm, that this does work as well as svn. Stefan -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Another FlightGear Package for Sale: Illegal?
On Tuesday 22 September 2009 14:04:16 Jon S. Berndt wrote: > This looks much more problematic: > > http://www.flightprosim.com/disclaimer/ "copyrighted under United States and other World Wide Patents" A little confusion of totally different laws... But interestingly from the front page: "There is no one company who published this software. It is a cooperative flight simulator development project. There are a wide range of people interested and participating in this project. This is truly a global effort with contributors from just about every continent. Interests range from building a realistic home simulator out old airplane parts, to university research and instructional use." The page and name looks and sounds somehow familiar. Haven't we had them before? > > From: Jon S. Berndt [mailto:jonsber...@comcast.net] > > Subject: Another FlightGear Package for Sale: Illegal? > > > > We all know by now that under certain conditions one can sell open > > source software packages such as FlightGear. However, it seems to me > > that this web site is problematic in several ways, > > > > - copyrighted screen captures may be used > > - company names are used (Boeing, Airbus, etc.) > > - I don't see any mention that the code can be downloaded anywhere 1 and 2 are bad. 3 is no problem, since only on delivery they have to include the source code or a written offer to supply it. Since they are advertising the multi player feature: how about periodically broadcasting a message via MP servers that users are using free software called FlightGear available at flightgear.org? Stefan signature.asc Description: This is a digitally signed message part. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gitorious repositories for FlightGear and SimGear
On Saturday 19 September 2009 21:29:27 Tom P wrote: > But if bandwidth becomes a problem, we could provide read-only clones of > the fgdata repository. > git://source1.flightgear.org/fgdata > git://source2.flightgear.org/fgdata > .. > which pull automatically from the main repo. > In fact, 3 repos on mapserver.flightgear.org could easily be setup to > mirror gitorious.org instead of CVS. > > And in the end, gitorious already hosts Qt, I'd be surprised that we > require more bandwidth than that! I could add a server in Germany hosted at hetzner.de. I have about 700GB more disk space than I need and I got unlimited traffic (if I exceed 2TB, bandwidth gets reduced to 10MBit/s) of which I need just a few GB. So if this could help, I'd be glad to do it. Stefan signature.asc Description: This is a digitally signed message part. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
On Wednesday 02 September 2009 17:55:07 Curtis Olson wrote: > In addition, I am self hosting our master CVS repository which means that > if my machine breaks, I personally am on the hook to drop everything else > and do whatever it takes (ranging from hardware, to OS, to security, to > whatever ...) to find and fix the problem before we can get our repository > back online. What if I happen to be on vacation or on a work trip or get > hit by the proverbial beer truck and then a problem develops with the > server? Using a decentralized VCS this is no longer a problem, since there is no master repository anymore. So if yours goes down, people can still continue to work. All that would be broken is the checkout links on the website. If we do not dare to move to git directly, I'd be all for going to SVN. It would be an improvement at least. But considering that many FG developers already use it, the much increased fail safety, local committing, easier patch sharing and improvements for model developer groups like AJ mentioned and quite a few more advantages, I think we should really make an effort to go all the way. Cheers, Stefan signature.asc Description: This is a digitally signed message part. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic input protocol delay
On Wednesday, 22. July 2009, Peter Völk wrote: > someone > advises to use Vsync to slow down the framerate, but as I use a TFT, it's > not really a possibility. Why would that not be possible with a TFT? Usually TFTs run at 75Hz which is far below the problematic 110. So it sounds like a sound solution. Regards, Stefan -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Start up Problems
On Sunday, 24. May 2009, Barry Fawthrop wrote: > I recent upgraded to the new version downloaded and compiled the source > not the apt binary for debian. Just a view guesses: did you upgrade the base package, too? Do you use a very recent OpenSceneGraph version? Regards, Stefan -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgjs segfault
On Thursday, 14. May 2009, Matthew Gibson wrote: > Sorry, I can't figure out how to reply to messages on mailing lists. > > But I found the issue. > > jssuper .h and .cxx don't assume the joystick numbers are in order. They > use a first and last variable, as well as an activeJoysticks number of > joysticks. I assume this is because, as with my system, the joysticks > aren't necessarily in order. > > fgjs.cxx DOES assume they are in order. > > jss->firstJoystick(); > fstream *xfs = new fstream[ jss->getNumJoysticks() ]; > > My first joystick is #2, my num joysticks is 1. Well, as it's my bad, I'll have a look at it later today, when I return from the airfield. Many thanks for this perfect bug report. Stefan -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hypothetical gpl question
On Tuesday 17 March 2009 14:11:38 Ron Jensen wrote: > On Tue, 2009-03-17 at 13:43 +0100, Stefan Seifert wrote: > > On Tuesday 17 March 2009 13:34:19 Curtis Olson wrote: > > > Here's a question: Does a 3rd party have the > > > right to ask for the modified source code, even if none of the entities > > > receiving the modified program don't care to ask for the source code? > > > > In short: no. The GPL doesn't require any rights for the whole world, but > > just for the users. This makes the GPL a perfectly acceptable license > > even for work with only one intended customer. > > Stefan's answer would allow company "A" to restrict the potential > customer's freedom to redistribute flightgear. Anticipated and > specifically addressed in GPL v2 Bottomline: no matter how often I read that darn license, I'll always forget important part when feeling the need to answer questions about it. Sorry for the confusion and thanks for clearing that up. Just a note: if the demo already contains the source code, then there does not have to be a written offer (or the referal to the written offer) for any third party, which would indeed be the case, I incorrectly simplified it to. Stefan signature.asc Description: This is a digitally signed message part. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hypothetical gpl question
On Tuesday 17 March 2009 13:34:19 Curtis Olson wrote: > Here's a question: Does a 3rd party have the > right to ask for the modified source code, even if none of the entities > receiving the modified program don't care to ask for the source code? In short: no. The GPL doesn't require any rights for the whole world, but just for the users. This makes the GPL a perfectly acceptable license even for work with only one intended customer. Stefan -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Saving Instant Replay to a File
On Tuesday 10 March 2009 14:16:23 Matthew Barousse wrote: > Hey all, > I'm currently attempting to modify flight gear, so that I may save and > re-play flights, exactly like the instant replay feature, but with a save > file. > > My next task is to implement a save-to-file feature. I was thinking the > easiest path would be to write the instant replay memory buffers > (FGReplayData, replay_list_type) out to a file, and modify the replay > method to read that file, instead of straight from the memory. > > I'm just wondering if anyone can foresee any problems with what I'm doing, > or has any pointers or tips for me? I'm just getting started with FG > development, and it's a bit overwhelming. This sounds very interesting. I think the replay feature needs quite some love anyway. For example, its still a mix of replayed and current properties. One cannot really replay a landing on the carrier, because the carrier's position is not recorded but still updated, so it looks like one's landing in the air. Stefan signature.asc Description: This is a digitally signed message part. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weird memory bloat
On Wednesday, 28. January 2009, John Denker wrote: > Ridiculing the bug report will not make the bug go away. I did not want to ridicule the report in any way. Apologies if it came like that. I just wanted to point out, that measuring memory usage unfortunately is not as easy as it looks (no, the memory usage number, Windows is displaying is not the whole truth either). I can't remember reading something about the swapping in your report, but that may just be my memory. Of course you're right: the swapping is a clear indicator. Had my own problems with FG's memory usage, too. But a friend solved it for me by giving me 2GB additional RAM as a birthday present. Stefan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weird memory bloat (was: engine reconfiguration?)
On Wednesday, 28. January 2009, John Denker wrote: > On 01/28/2009 02:25 AM, Erik Hofman wrote: > > I didn't check it myself yet, but every once in a while I have to do a > > 'make clean' before 'make install' for this sort of things (both for > > Simgear and FlightGear) > > Good advice; thanks. > > Alas after doing that, the memory bloat remains, as bad as ever. > I saw it peak at 905 megs at KASE before falling back to 888 megs. "bloat" is a hard word for something, which you did not even measure yet. The VIRT column of top is basically useless for getting the memory usage. It's just the virtual address space allocated to that process. That includes: * memory allocated with malloc but not yet used, which means that there is no physical RAM used for it * mmap'ed files * shared memory and I'm sure some more which I'm not thinking of. According to VIRT, amarok uses > 730MB on my system which is a quite ridiculous number. If you're interested in memory usage of a process, a _start_ is the RES column. It's far nearer to the "truth" even though it does not count swap usage of the process. But if FG causes swapping, you don't need top to tell you :) That'd be obvious. Stefan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] engine reconfiguration?
On Wednesday, 28. January 2009, Jon S. Berndt wrote: > Is there sometimes confusion as to how or where to apply changes to JSBSim > code or aircraft models? Do we need to work on easing the process of > integration into FlightGear? More frequent synchs? (we'd need additional > volunteers, and/or I'd have to step in - I don't want to make more work for > anyone else). Speaking of volunteers: what does the sync work look like? Stefan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 33, Issue 26
On Saturday, 24. January 2009, syd adams wrote: > My thoughts were to move the "extra" or "non sellable" aircraft out of cvs > /data , not to erase them completely I am working on the Boeing 777 , > so this issue is of some interest to me Why is it, since the 777 is clearly as sellable as any other FG aircraft? Stefan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing and disclaimers for aircraft models
On Thursday, 22. January 2009, Tim Moore wrote: > We can't say that "all the models in the repository are covered by the GPL" > and have models in there that are not. This is a terrible trap for anyone > wanting to use FlightGear in any professional setting. Please do not confuse the software license with other things like trademark law. There will always be things like trademarks, patents, warranty or other local laws that may add further restrictions to what you can do with software regardless of the software's license or it's validity. There are tons of free software that may not distributed as freely, as it's license (mostly GPL) would allow. I mentioned Mozilla Firefox earlier. But there's also things like simple mp3 codecs. Doubtless free software, but not as easy to distribute because of patent law in some countries. A copyright license can and should only care about copyright. It cannot free you from checking your other laws that may prevent you from doing what you want. Maybe you are not even allowed to sell _any_ software. That's not even a contrieved example: a four-year-old is not allowed to do so because he cannot enter a valid contract (which a sell would be). Does that make the GPL invalid? Of course not. So your museum just has two choices: * contact Boeing and get a license not for the software, but for the trademark * remove the usage of the trademark from the software before selling it There's nothing we could do about this. Except of course to abstain from using the trademarks in the first place. But as we have permission to use them for the stuff we really care about, I see no strong enough reason to do so. I'd just be nice to people and remind them to check their trademark usage. Stefan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing and disclaimers for aircraft models
On Thursday, 22. January 2009, Jon S. Berndt wrote: > Since it appears as though JSBSim will use the product identifiers > (e.g..Boeing 737) in a descriptive manner, and no profit will be derived > from said usage, then we have no objection to inclusion of the product > identifiers on the software. However, if a situation arises in which the > aircraft models are to be sold for a profit, please contact us to discuss > implementation of a Trademark License Agreement for the sale of consumer > products. Looks like a siple case to me: no copyright law involved, just trademark law. This should not be any problem for GPL'ed distribution. A very good example for this whould be the well known Mozilla Firefox browser. No one would argue that the software is free as it's MPL/GPL dual licensed. But they do not allow modified versions to use their trademark and call it Firefox. That's why it's called Iceweasel on Debian. So Boeing is actually more permissive than the Mozilla Foundation as they allow the trademark to be used in any non-profit situation. If someone want's to sell FlightGear or such models, they have to ask Boeing for a trademark license agreement or simply remove the trademark's usage from the software (like Debian does). So the way to go seems to be just to add a notice, that the model uses Boeing's trademark with clearance for any non-profit distribution while for other uses, the trademark's usage has to be removed or Boeing contacted. Not an additional restriction of the software license, but of the trademark usage. Stefan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Aircraft/Boeing314 Boeing314A.xml,
On Wednesday, 21. January 2009, Martin Spott wrote: > b) The GPL states that "You may charge a fee for the physical act of > transferring a copy, [...]", but "You may not copy, modify, sublicense, > or distribute the Program except as expressly provided under this > License". > > Now, how would you interpret the vague term of "selling a software" ? > The word "selling" is probably a bit unfortunately choosen here, but > depending on one's interpretation, the note might conform pretty well > with the ideals of the GPL, Please, as we are no lawers ourselfs, and as the statement in the GPL may be easily misunderstood, accept the Free Software Foundation's answer to this question: Does the GPL allow me to sell copies of the program for money? Yes, the GPL allows everyone to do this. The right to sell copies is part of the definition of free software. Except in one special situation, there is no limit on what price you can charge. (The one exception is the required written offer to provide source code that must accompany binary-only release.) http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMoney Stefan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] new JSBSim CVS for FlightGear?
On Monday 12 January 2009 15:29:43 gerard robin wrote: > On lundi 12 janvier 2009, Erik Hofman wrote: > > > > True, but this requires a base package update to work correctly. Which > > is better to delay a few days so the binary only bugfix release can get > > released. > > Ouups > sorry i thought that we could get profit, at least with FG 1.9, of a nice > and huge update of the c172 , which is today wrong and broken ( reffering > to the large talk on that mail list last year ). I think this is a very good example of why regular releases are good. When the next release is already in sight, the pressure to push "huge updates" into maintenance releases lowers considerably. So, yes, it would be nice to have a much better c172 now, but it's still ok, to see it fly in a few months, perhaps even still better. And related: having release branches would be at least equally nice. As of now CVS head does not even represent the current development version anymore, because people are holding back patches not fit for a maintenance release. As branching in CVS is very expensive, we now have another reason to migrate to _any_ other VCS. So, is there anything I could do to help speeding up this migration? Stefan signature.asc Description: This is a digitally signed message part. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 1.9.1
On Monday, 12. January 2009, Alexis Bory - xiii wrote: > Also, using gdb prevents this segfault to appear. It looks like having > a timming issue in the different processes. When it's not reproducible with gdb, you can enable core dumps with "ulimit -c unlimited" before running FG. If it crashes it should leave a core dump (can be serveral GB! So it may take a while...) which can be debugged with gdb. Stefan -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with 1.99.5
On Wednesday, 03. December 2008, Jon Stockill wrote: > Just out of interest which version of OSG are people planning to link > the release against? Are we going to wait for a 2.8 release, or go with > one of the 2.7 developer releases? Looking at previous OSG release dates (2.2 October, 2.4 April, 2.6 August) the next release cannot be that far away, so it might make sense to wait. And maybe they would consider releasing soon if nicely asked? Stefan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 1.99.5: Release Candidate
On Sunday, 30. November 2008, Heiko Schulz wrote: > > Which format "zip" isn't it MS windows > > format. ? > > > > And what about "tar.gz" format which is a > > standard too :) > > .zip is mainly used on Win but it can also opened on Linux and Mac. > But tar.gz can be used also on win but can be opened on win with the > OpenSource program 7-zip. > > Tar.gz compresses IMHO much better, so we should use that. I think the question is not about the archive format itself, but about the contents. That is for example if all the contents are in a folder already or unpack directly into the current directory. Stefan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d clouds interaction with overcast layer
On Thursday 27 November 2008 16:21:45 Frederic Bouvier wrote: > - "Curtis Olson" a écrit : > > The solution is to draw transparent objects in sorted order back to > > front ... including clouds ... so in this case it appears that the 3d > > clouds are being drawn before the 2d cloud layers, and in reality the > > 2d cloud layers need to be intermixed inthe correct draw order with > > the 3d cloud layers. > > The 2D cloud layers used to be drawn from top to camera altitude for upper > layers and from bottom to camera altitude for lower layers. The 3D layer > should be included in this order now. Works easily for 2D layers, but won't for 3D. 3D clouds can streck from below the camera to above the camera and thus hide both, layers below you and above you at the same time. -Stefan signature.asc Description: This is a digitally signed message part. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] release thoughts
On Monday 17 November 2008 09:20:14 James Turner wrote: > > In the past I've worked on binary distributions for various GL-based > projects on Linux, one using VTK and one using OGRE. In both cases we > ended up shipping libstdc++ as well - in order to have a chance at > portability, the only externals you can rely on need to have C > linkage, not C++ linkage. It is possible to make C++ dependencies > work, but it seems to complicate things unduly, whereas shipping the > libstdc++ that the binaries were built with is easy. > > Maybe this situation has improved recently, however - my knowledge of > this is currently two years old. AFAIK libstdc++ is in LSB nowadays, so the situation should be better. > On 16 Nov 2008, at 18:07, Tim Moore wrote: > > On Linux you might think that we could blow this off and depend on the > > distributions' OpenSceneGraph package, but this is not practical. > > OpenSceneGraph > > releases come fast and furious; we will be depending on OSG 2.8, and > > (for > > example) my distribution of choice is still supplying 2.2. So we > > need to supply > > to proper version. To me it sounds like making sure that more recent OSG packages are available for these distros is the way to go. With the openSUSE build service, it's very easy to build and provide packages even for distributions you don't have yourself. I'd say it's definitely worth a look: https://build.opensuse.org/ Stefan signature.asc Description: This is a digitally signed message part. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to lower how much scenery gets cached:
On Thursday, 13. November 2008, Curtis Olson wrote: > How much memory do you have? Is it possible to add some memory to get > yourself up to maybe at least 512Mb total? Just a side note: even 512MB is very little nowadays for FG. I'm running with 1GB and am very much looking forward to getting more next week so I do not have to close everything including my mail client while FG is running... Regards, Stefan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An off topic question.
On Friday, 17. October 2008, Tobias Nielsen wrote: > I have a version in my svn repository that i am doing active > development on several different machines. I am not allowed to do any > commits to the repository before the code is in a somewhat stable > state. For that reason i each time perform a "svn diff . > > something.patch" when i want to merge the development of two different > machines.. Not having it used myself, but I think I heard that svk can help you in this situation: http://svk.bestpractical.com/view/HomePage AFAIK It should allow you to commit locally, transfer patches and do an svn commit when it's ready. Would be interesting, if it really helps you :) Regards, Nine - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] F-14 was Call for aircraft nominations
On Sunday, 05. October 2008, Alexis Bory - xiii wrote: > Heiko Schulz wrote: > > Forgot ne aircraft: the F14 is really nice and has a lot of features! > > It should be in the package! > > Thanks :-) > > BTW: I'm currently preparing an important update, there will be a lot of > changes and cleaning made on the CVS f-14b and it may be partially > broken until late this evening. So please if you want to test it be > aware that the best is to wait for a f-14b CVS update tomorow 2008/10/06. Just wanted to post a Thank You for this wonderful aircraft model. It's just so darn cool watching it fold it's wings back in flight :) I think it definitely is one of the aircrafts that really show how much FG can do. Regards, Nine - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
