Re: [Flightgear-devel] Segfault with OSG multi threading
Good morning, On Monday, May 30, 2011 19:54:31 ThorstenB wrote: On 30.05.2011 19:25, Stefan Seifert wrote: 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? Well, wouldn't surprise me to find more related multi-threading issues. Not sure how long OSG itself supports it, but I guess it wasn't a major priority at the time when FG was adapted to OSG. And I'm sure more fixes will be necessary to safely support it. Well, there are several threading issues left in flightgear. Openscenegraph supports threading *very* well since ll tha time I know this project. But flightgear was written initially and has still left plenty of single threading assumptions that are not so easy to remove. I always tried to move into this direction, but never got this into a state where I knew that everything *should* work. I know that some of us regularily play with the threading stuff, And I thought that in the time I have not followed fightgear too close Tim had make that work. But when looking into this, I realize that there is still plenty of stuff to do in this area. Also this explaines various crashes on the LinuxTag booth. If you use multithreading it works in the current state just by accident ... The particular source lines also have an //OSGFIXME comment - another hint that work was left behind. Yep... Try replacing the calls to SGIsOpenGLExtensionSupported - they provide constant information anyway. It'd be enough to check version/capabilities once during init and then use constant data at run-time. Try if that helps. Patches welcome :). Well, this is even more complicated: What happens is that in a multithreaded environment we do *not* have *any* OpenGL context active in the main thread. This means whatever code calls either some of the osg extension query function with a second argument of true or calling the above function can result in undefined behaviour - which is what you experience. Only the draw thread has a opengl context guaranteed. Which makes it immediately clear that the only place where we can reliably call these functions is duning the draw traversal. The osg extension functions take two arguments the first one is the context to ask for, which we currently just hope that all context support the same set of features - which is not true in certain configurations. And the second argument is to really ask for the extensions or use the cached result by just testing against a bool value. On a singlethreaded environment we just have the current thread bound to the current context and everything works magically. But on multiple threaded osg this fails. And depending on the opengl driver it may fail or may not fail ... Also, the mentioned call is relatively slow as it searches a string for a substring where it is in the end mostly a boolean operation to decide if a combination of opengl features is availalbel or not. So if you are in a runtime sensitive code path, don't use SGIsOpenGLExtensionSupported directly. 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 ... Greetings Mathias -- 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 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] SimGear compilation problem with MS VisualStudio 10
Please see inline and below: On Friday, May 27, 2011 05:23:59 PM Frederic Bouvier wrote: AFAICS, MSVC2010 compiles current Git version without any problem. The OP doesn't say what version he is trying to build, but if I recall correctly, this error was fixed months ago. See http://gitorious.org/fg/simgear/commit/acbc09b232e4570462d5936eaf20d267153 0d8f4 Last tested Boost is 1.44.0 for me. Regards, -Fred All, sorry for not staying on top of this over the weekend. I will look into all the comments posted, double check my git checkout and come back with either a success message or a more detailed failure description. Thanks for hanging in there with me Claus -- Claus Christmann, M.S. Graduate Research Assistant Georgia Institute of Technology 270 Ferst Dr NW Atlanta, GA 30332-0150 http://uav.ae.gatech.edu -- 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] terragear - file src/Lib/Optimize/genfans.cxx
Geoff, I applied both of your patches, see here: https://gitorious.org/papillon81/terragear-cs Until now I had no crashes or negative effects on the resulting scenery. However, there IS a problem, unrelated to your patches, for which I hope to get some help. I create large chunks of scenery with CORINE and OSM data. fgfs-construct runs quite some hours for it and i see the processing is fine. Then, after some time (say 6 hours), all I see in the console output are colums with Default=x where x is a number between 1 and 3. This goes on and on for hours and I stopped it yesterday. Is this supposed normal behaviour? Maybe the process is hanging somewhere, the CPU is buisy the whole time. Any ideas? Cheers Chris -- 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
[Flightgear-devel] ..ati, radeon etc framerates, was: Segfault with OSG multi threading
On Tue, 31 May 2011 14:54:16 +0200, Stefan wrote in message 201105311454.16662.n...@detonation.org: 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 :) ..what framerates do you get with the other drivers? ATI/AMD's closed source fglrx, and radeondh? -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- 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
[Flightgear-devel] 2d panel visibility
I could be imagining this, but I seem to recall a while back, someone asking if it was possible to keep a 2d panel visible all the time, even in external views. I just took a quick peek at .../Cockpit/panel.cxx and it doesn't appear that we have the ability to do this, but I just thought I'd ask in case there is some other mechanism someone has added? I am working on a project where we are modeling a skydiver in free fall, and we want to display some basic information on the edge of the screen (like decent rate). But because this is not an aircraft, it makes more sense to use external views. Also we are trying hard to avoid needing to modify source code, and we'd like to do this in v2.0 (the most current release). The HUD would be another alternative, but we'd like to avoid needing to extend the HUD code to add our specific widgets. Perhaps we could use gui widgets and display the information numerically, but an instrument communicates the data so much better. Are there any other options or ideas that I'm missing? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] 2d panel visibility
On Tue, 31 May 2011, Curtis Olson wrote: I am working on a project where we are modeling a skydiver in free fall, and we want to display some basic information on the edge of the screen (like decent rate). But because this is not an aircraft, it makes more sense to use external views. Also we are trying hard to avoid needing to modify source code, and we'd like to do this in v2.0 (the most current release). You could use the display class in Nasal/screen.nas to display chosen properties. It might not be pretty enough for your application, though. (I don't remember if it supports other presentations than just property values.) Example (loosely) from ZLT-NT: var left = screen.display.new(20, 10); # Static condition left.add (/fdm/jsbsim/instrumentation/gas-pressure-psf); left.add (/fdm/jsbsim/buoyant_forces/gas-cell/ballonet[0]/volume-ft3, /fdm/jsbsim/buoyant_forces/gas-cell/ballonet[1]/volume-ft3); left.add(/fdm/jsbsim/static-condition/net-lift-lbs); left.add(/fdm/jsbsim/atmosphere/T-R); left.add(/fdm/jsbsim/buoyant_forces/gas-cell/temp-R); left.add(/fdm/jsbsim/ballonets/valve-pos-norm[0], /fdm/jsbsim/ballonets/valve-pos-norm[1]); Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- 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] 2d panel visibility
Am 31.05.11 20:00, schrieb Curtis Olson: Are there any other options or ideas that I'm missing? Can you spawn an external application and render it's output window on top of FlightGear? If so, fgpanel might be worth looking at. You find it in utils/fgpanel and an example how to use it is in Aircraft/SenecaII/Panels/Panel1.xml. Torsten -- 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] 2d panel visibility
On Tuesday, May 31, 2011 11:00:58 AM Curtis Olson wrote: I could be imagining this, but I seem to recall a while back, someone asking if it was possible to keep a 2d panel visible all the time, even in external views. I just took a quick peek at .../Cockpit/panel.cxx and it doesn't appear that we have the ability to do this, but I just thought I'd ask in case there is some other mechanism someone has added? I am working on a project where we are modeling a skydiver in free fall, and we want to display some basic information on the edge of the screen (like decent rate). But because this is not an aircraft, it makes more sense to use external views. Also we are trying hard to avoid needing to modify source code, and we'd like to do this in v2.0 (the most current release). The HUD would be another alternative, but we'd like to avoid needing to extend the HUD code to add our specific widgets. Perhaps we could use gui widgets and display the information numerically, but an instrument communicates the data so much better. Are there any other options or ideas that I'm missing? Thanks, Curt. Have you thought about modeling the skydiver as an aircraft with the cockpit being the view out of his/her goggles? The panel would be nothing and the instruments could be just positioned about a meter in front of the pilots point of view. You could then keep the instruments in view as the pilot changed his view direction (IE. look up, down, left, right) by rotating them about the pilots head. You should be able to do all of this using the existing XML. Or you could create a 3D model for the skydivers body and possition the instruments on his/her body (IE on the top of the belly mounted chute pack) so that you need to look down to see them. Hal -- 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] 2d panel visibility
Thanks everyone for the responses. So far the Anders' suggestion of using screen.nas seems to have the most promise. Torsten: I have another project I want to use the fgpanel system for, but with this project we are trying to keep the logistics of starting things up as simple as possible, also I'm not sure how you would keep the fgpanel display in front of the FlightGear display if you had to click on the flightgear display to interact with it? Hal: it's important with this particular project to have the instrumentation attached to the screen when the view changes or pans around, even in tower or fly-by views we want to see the instrumentation clearly. Regards, Curt. On Tue, May 31, 2011 at 2:51 PM, Hal V. Engel wrote: On Tuesday, May 31, 2011 11:00:58 AM Curtis Olson wrote: I could be imagining this, but I seem to recall a while back, someone asking if it was possible to keep a 2d panel visible all the time, even in external views. I just took a quick peek at .../Cockpit/panel.cxx and it doesn't appear that we have the ability to do this, but I just thought I'd ask in case there is some other mechanism someone has added? I am working on a project where we are modeling a skydiver in free fall, and we want to display some basic information on the edge of the screen (like decent rate). But because this is not an aircraft, it makes more sense to use external views. Also we are trying hard to avoid needing to modify source code, and we'd like to do this in v2.0 (the most current release). The HUD would be another alternative, but we'd like to avoid needing to extend the HUD code to add our specific widgets. Perhaps we could use gui widgets and display the information numerically, but an instrument communicates the data so much better. Are there any other options or ideas that I'm missing? Thanks, Curt. Have you thought about modeling the skydiver as an aircraft with the cockpit being the view out of his/her goggles? The panel would be nothing and the instruments could be just positioned about a meter in front of the pilots point of view. You could then keep the instruments in view as the pilot changed his view direction (IE. look up, down, left, right) by rotating them about the pilots head. You should be able to do all of this using the existing XML. Or you could create a 3D model for the skydivers body and possition the instruments on his/her body (IE on the top of the belly mounted chute pack) so that you need to look down to see them. Hal -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] heads up: FlightGear release plan
Am 22.05.11 14:37, schrieb ThorstenB: Hi, since there were no major objections to the release plan, we're proceeding as proposed. Current status: * We've officially grounded the releases/2.2.0 git branches yesterday. The flightgear/simgear releases/2.2.0 branches were merged back to master (not next! master always contains the latest release). However, as proposed, we won't invest any more time into 2.2.0, so there'll be no binaries on the download page, no updated aircraft downloads, no announcements, etc. * git/next is bumped to version 2.3.0 now. Actually we should have done so when we branched releases/2.2.0 in January. Remember. it's odd minor versions for the developer version now (git/next), even minor numbers for releases. * Hudson is prepared for providing release binaries and installers (thanks James!). Once we create a new release branch, Hudson should start building the binaries/installers (see Hudson's Windows-release, Mac-release, Linux-release projects). As usual, these will be updated hourly. We'll also provide complete Win/Mac installers (including fgdata base package) regularly, maybe about weekly, so these can be used for wider beta testing. We can't include the base package in the _hourly_ installers though, due to bandwidth/size limits (almost 400MB for the fgdata base package). * We also started assessing tracker issues (thanks Gijs!). Some were already fixed in the last days. And it doesn't look too bad, few issues are highly critical. However, there are some areas where we're missing people, for example for some (new) FDM, and a number of ATI-graphics issues. Have a look at the tracker: http://code.google.com/p/flightgear-bugs/issues/list Finally, as a reminder now: Only 4 more weeks to 2.4.0 feature freeze, remember June 17th, when we'll close sg+fg next branch, and (!) fgdata master for 4 weeks. Only bug fixes should be committed after June 17th. releases/2.4.0 will be branched on July 17th, when the main developer branches will be bumped to 2.5.0 and reopen for new features. Beta testing for 2.4.0 will continue for another month after that, till August 17th. But all this was already described in the release plan http://wiki.flightgear.org/Release_Plan cheers, Thorsten On Do, 2011-05-19 at 14:29 +0200, Torsten Dreyer wrote: Hi everybody, during this year's LinuxTag, Martin Spott, Mathias Fröhlich, Thorsten Brehm and myself developed a strategy and a concept about how to kick out new releases of FlightGear on a regular schedule. Please find our first draft here: http://wiki.flightgear.org/Release_Plan For the impatient reader, this is the abstract: We plan to have two releases per year, one in February, one in August. The first scheduled release following this concept will be 2.4.0 in August this year, 2.6.0 is scheduled for February 2012. If no major objections arise, we will set the version number on the current development stream to 2.3.0 and will call out a feature freeze on June 17th. Any comment and certainly any help for actually preparing the release is welcome. Thanks, Torsten Can you please update http://wiki.flightgear.org/Release_Plan with this very important information ? Something like a short description of current state ? Thanks a lot, Yves -- 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
[Flightgear-devel] FlightGear.org updated!
Hi Curt May I ask you to update your flightgear.org pages just a bit? Will not take more than 10 minutes! No graphical changes, no code changes, just update text ;-) I ask you for updating text sections like source code or cvs resource. Sorry for that, but your february-2010-pages looks like a disservice for all other sites built for this project at the moment. Thanks a lot, Yves -- 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] Rating System Redux (was Re:Flightgear-devel Digest, Vol 61, Issue 12)
Hal, I can't follow your logic - because there are some aircraft that need a lot of work, the system shouldn't recognize advanced features in other aircraft that do have them? I also disagree with Stuart that such advanced features are nice-to-haves and add little to the simulation - why the hell are we including them then? Do the stores so nicely added to the P-51 add nothing? On the other hand, the ability to change liveries adds to the model? Sure doesn't wring my withers, but I suppose the airliner aficionados (and I'm not one) absolutely must have that. The P-51 is a superb model already, and at a reasonable frame rate here - about 75% of my benchmark figure. It would benefit from a tutorial on the start procedure - but apparently that would win no points either. That seems to be a missed opportunity too. I suppose the P-51 FDM is accurate - but I find it not all that pleasant to fly. I would say that you have probably slightly underrated its score. In the final analysis - the system currently proposed is only marginally better than the current wet finger in the air method. I think we are falling a bit short here in our aim to be both objective, and to tell users more about the available aircraft. In particular, the failure to tell users that they need a powerful system to use a model, and something about the difficulty of use, is going to disappoint and or frustrate users. Vivian -Original Message- From: Hal V. Engel [mailto:hven...@gmail.com] Sent: 30 May 2011 23:45 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Rating System Redux (was Re:Flightgear-devel Digest, Vol 61, Issue 12) On Monday, May 30, 2011 12:47:41 PM Stuart Buchanan wrote: I don't have a good answer for the other items. Some are nice-to-haves that enrich the simulation experience but don't impact simulation of flight itself, but others (such as a co-pilot) are more important for multi-crew aircraft. Call them all advanced features. That could be a/the criterion for advanced production I'm not sure. The Advanced production bar is already very high - two 5s and two 4s. I'm not sure if any aircraft will actually gain it! I would expect that at this point only a few aircraft out there are close to or are advanced production quality. It is a very high standard and any aircraft that is that far along should really stand out. I would expect that most of the most advanced current models only need perhaps 1 or 2 points to get there but adding points when the models are that far along is a lot of work. But I would be surprised if there were more than a handful of aircraft that were far enough along to only need 1 or 2 points to become advanced production. I think I agree with Stuart that having some things called advanced features does not add much if anything to the system particularly when we have so many models that are missing many basic things. An example of one that is close but needs more work is the p51d-jsbsim model. It only needs to improve the external model (add livery support to go from a 3 to a 4) to get to production status and then add one more point in cockpit, external model or systems would make it advanced production. Currently it has the following ratings: rating FDM type=int5/FDM systems type=int4/systems model type=int3/model cockpit type=int4/cockpit /rating The 3D modeling stuff is not my strong suit but I do have new more accurate 3D models for the fuselage and wing (including flaps and aileraons) for the P-51D that I created a while back. I have also more accurately modeled the cooling inlet passages and the oil and coolant radiators so that these will look correct (once textured) when looking into the cooling inlet. I need to uvmap all of this stuff now and this is where I get stuck as I can't figure out how to do this so that the resulting uvmaps can be used to create livery support. Having a nice user friendly uvmap for the fugelage and wings is more or less nessary to move ahead with libery support I think. For Systems adding emergency gear release support, oxygen system support, full cooling system support, VHF radio support, rear warning radar support, IFF support and some missing electrical system stuff would increase this to a 5. The 3D models for the controls for all of these systems are already in the cockpit. One comment about systems. For the P-51 series there are two cooling doors that are used to control cooling airflow. One for the engine coolant and one for the oil cooler. JSBSim has support for the coolant door controls but not for the oil cooler door controls. I have the automatic coolant door stuff modeled but not the automatic oil cooler stuff because of this. I also need to add manual overides for these at some point (the controls are in the cockpit but currently only allow for automatic control). What I am getting at is that some systems can not be fully
Re: [Flightgear-devel] 2d panel visibility
On Tue, 31 May 2011 15:46:32 -0500, Curtis wrote in message banlktiklhbuyyxd93edqa_mm+5fv88d...@mail.gmail.com: Thanks everyone for the responses. So far the Anders' suggestion of using screen.nas seems to have the most promise. Torsten: I have another project I want to use the fgpanel system for, but with this project we are trying to keep the logistics of starting things up as simple as possible, also I'm not sure how you would keep the fgpanel display in front of the FlightGear display if you had to click on the flightgear display to interact with it? Hal: it's important with this particular project to have the instrumentation attached to the screen when the view changes or pans around, even in tower or fly-by views we want to see the instrumentation clearly. ..don't we do FPV-style OSD? E.g.: http://www.youtube.com/watch?v=rmCYYkehYrIfeature=related from http://www.google.no/search?num=100q=FPV+OSD or http://www.google.no/search?q=FPV-style+OSDhl=enprmd=ivnssource=univtbm=vidtbo=usa=Xei=QmDlTcPAGNDEsgaL2bDrBQved=0CC4QqwQbiw=1805bih=1022 ..me, I just use the HUD. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- 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] terragear - file src/Lib/Optimize/genfans.cxx
Hi Chris, Glad the rough 'fixes' I provided worked a little for you... have yet to clone your 'papillon81' clone, and try it... but... While it is agreed on this list everyone seems to really _LOVE_ extreme brevity, (perhaps except me ;=)), your post just did not tell me enough ;=(( I searched the entire terragear-cs source for - Default=, and did not get a single hit, well one ... Default=%s\n, out_file), but that's obviously not it, so no idea where to look ;=(( Maybe the output is in simgear, or some of the other libraries that are included in fgfs-construct... Spaces and case are vitally important... But what is the console output immediately prior this 'continuous' output? Maybe that would provide more clues as to where it is in the processing... It is clear fgfs-construct is getting 'stuck' somewhere, but simply need more information... It is certainly _NOT_ 'normal' behavior, and historically (I assume Curt ;=)) implemented some draconian 'rlimit' - setrlimit(RLIMIT_CPU,timeout), to abort after a period of time, which is just NOT available in my WIN32 environment, to avoid such a 'forever' loop... At the time I understand, they were building the WHOLE WORLD world of scenery, and did not want the process 'stuck' on some bucket, or group of buckets... So while I also now play with a Ubuntu linux build, I try HARD to find 'other' solutions for WIN32... like finding, and fixing the 'reason' for such 'forever' loops... So with more information, maybe we can track down, and 'fix' it, forever ;=)) But, _BUT_, be aware, some others, who have tried my 'fixes', including myself ;=)), especially regarding the 'priorities' have succeeded in only producing really _MESSED_ up scenery - see - http://geoffair.org/tmp/mess-01.ppm or http://geoffair.org/tmp/mess-02.jpg and these were generated using my modified WIN32 fgfs construct exe - http://geoffair.org/fg/fgfs-054.htm#downloads so I feel I am very _FAR_ from the solution ;=(( Any input from others, with knowledge, would really HELP... Regards, Geoff. -- 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] heads up: FlightGear release plan
we need to sit on this as 2.2.freeflightsim.org.. We need a marketing plam somwhat.. I hope we stick to release schedule.. On Tue, May 31, 2011 at 10:15 PM, HB-GRAL flightg...@sablonier.ch wrote: Am 22.05.11 14:37, schrieb ThorstenB: Hi, since there were no major objections to the release plan, we're proceeding as proposed. Current status: * We've officially grounded the releases/2.2.0 git branches yesterday. The flightgear/simgear releases/2.2.0 branches were merged back to master (not next! master always contains the latest release). However, as proposed, we won't invest any more time into 2.2.0, so there'll be no binaries on the download page, no updated aircraft downloads, no announcements, etc. * git/next is bumped to version 2.3.0 now. Actually we should have done so when we branched releases/2.2.0 in January. Remember. it's odd minor versions for the developer version now (git/next), even minor numbers for releases. * Hudson is prepared for providing release binaries and installers (thanks James!). Once we create a new release branch, Hudson should start building the binaries/installers (see Hudson's Windows-release, Mac-release, Linux-release projects). As usual, these will be updated hourly. We'll also provide complete Win/Mac installers (including fgdata base package) regularly, maybe about weekly, so these can be used for wider beta testing. We can't include the base package in the _hourly_ installers though, due to bandwidth/size limits (almost 400MB for the fgdata base package). * We also started assessing tracker issues (thanks Gijs!). Some were already fixed in the last days. And it doesn't look too bad, few issues are highly critical. However, there are some areas where we're missing people, for example for some (new) FDM, and a number of ATI-graphics issues. Have a look at the tracker: http://code.google.com/p/flightgear-bugs/issues/list Finally, as a reminder now: Only 4 more weeks to 2.4.0 feature freeze, remember June 17th, when we'll close sg+fg next branch, and (!) fgdata master for 4 weeks. Only bug fixes should be committed after June 17th. releases/2.4.0 will be branched on July 17th, when the main developer branches will be bumped to 2.5.0 and reopen for new features. Beta testing for 2.4.0 will continue for another month after that, till August 17th. But all this was already described in the release plan http://wiki.flightgear.org/Release_Plan cheers, Thorsten On Do, 2011-05-19 at 14:29 +0200, Torsten Dreyer wrote: Hi everybody, during this year's LinuxTag, Martin Spott, Mathias Fröhlich, Thorsten Brehm and myself developed a strategy and a concept about how to kick out new releases of FlightGear on a regular schedule. Please find our first draft here: http://wiki.flightgear.org/Release_Plan For the impatient reader, this is the abstract: We plan to have two releases per year, one in February, one in August. The first scheduled release following this concept will be 2.4.0 in August this year, 2.6.0 is scheduled for February 2012. If no major objections arise, we will set the version number on the current development stream to 2.3.0 and will call out a feature freeze on June 17th. Any comment and certainly any help for actually preparing the release is welcome. Thanks, Torsten Can you please update http://wiki.flightgear.org/Release_Plan with this very important information ? Something like a short description of current state ? Thanks a lot, Yves -- 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 -- 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] heads up: FlightGear release plan
Can you please update http://wiki.flightgear.org/Release_Plan with this very important information ? Something like a short description of current state ? Thanks a lot, Yves Hi Yves, this particular wiki page was written (mostly by myself) to document our release plan. I tried to make it as complete as possible but if anything is missing, please feel free to add it to the wiki. Thanks, Torsten -- 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] Rating System Redux (was Re:Flightgear-devel Digest, Vol 61, Issue 12)
I absolutely agree with Vivian. The users should know about planes that need much resources (CPU, RAM, VRAM). This value should not influence the total score. Maybe using the total score is not a good idea at all, because some users prefer the eye candy and don't worry about frame rate too much, others prefer an accurate FDM and a high framerate. So the total score doesn't tell the whole story! But the idea of showing the user individual scores (FDM, Systems, Cockpit, 3d model, + needed resources) is a good one! What do you think? -- 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
