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.. We are currently well on track. We fixed many bugs from the tracker and now that June has arrived, there are just roughly two weeks until we freeze 'next' for the final dustremoval session and before we branch for the release on July, 17th. 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] heads up: FlightGear release plan
Am 01.06.11 07:41, schrieb Torsten Dreyer: 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 Hi Torsten I only missed the statements from your message here in the list, which is very important to see current progress. Because i.e. Text on gitorious does not reflect the new plan. Sorry, I was away for some weeks ... Maybe I will add a box or something on top of the wiki page to reflect current state in two or three lines. I really like this effort with the release plan and I apologize, I didn’t want to come back to the project and as a first action I change this new wiki page. I missed such an effort a long time, I hope this becomes a real roadmap now. 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] terragear - file src/Lib/Optimize/genfans.cxx
Chris/Geoff, I normally see reams of these and other similar lines. I think that you are seeing some form of count for terrain type. My usual output has other textures mixed in there and only ever 3 as the number expressed. If you are using a hight level of detail (OSM residental) and processing a 10x10 then is will take a long time to complete and any tile that has a lot of detail will produce lots of the described output. I have also noticed that the generation takes a long time due to it being single threaded ( hogs a single core ). I have tried to use the server/client but found that it just doesn't appear to work anymore.. Jason Cox ( still building YSSY to YWLM ) On Wed, 2011-06-01 at 01:35 +0200, Geoff McLane wrote: 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 -- 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
Hi Torsten I only missed the statements from your message here in the list, which is very important to see current progress. Because i.e. Text on gitorious does not reflect the new plan. Sorry, I was away for some weeks ... Maybe I will add a box or something on top of the wiki page to reflect current state in two or three lines. I really like this effort with the release plan and I apologize, I didn’t want to come back to the project and as a first action I change this new wiki page. I missed such an effort a long time, I hope this becomes a real roadmap now. Thanks a lot, Yves Hi Yves and welcome back, the roadmap is there - now let's hope enough people are willing to follow us on that path. Currently the workload is distributed on the shoulders of just a few of us and every little help is very much appreciated. 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
[Flightgear-devel] High altitute/speed flights terrain engine problems
Another one, maybe final, attempt to attract FG community attention to high altitude/speed flights and current terrain engine problems with it. Current terrain engine makes flights on high altitudes or long flights on high speeds unreasonable. There is no Earth surface visible, only blue fog, but lags very big, fps may drop to one per second or less, simulation may crash on attempt to switch to other window and so on, because it still loads some terrain even if it is invisible to pilot and that terrain is unreasonably exact. It's all makes such flights, not easy on itself, unpopular by most of users. One option is fly complex craft and get some cool view, other option is to fly complex craft without view but with dropouts. No to say I am not competent enough to do something myself, but I need at least some help about where to start, for example, where to switch current terrain engine off completely and leave only fog to avoid terrain loading and lags. Because I do not want to overwhelm developers resistance to some improvements including and I am need to know what it will be accepted for sure to avoid unaccepted work. If not then not. With best regards, Slavutinsky Victor -- 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] High altitute/speed flights terrain engine problems
Current terrain engine makes flights on high altitudes or long flights on high speeds unreasonable. There is no Earth surface visible, only blue fog, but lags very big, fps may drop to one per second or less, simulation may crash on attempt to switch to other window and so on, because it still loads some terrain even if it is invisible to pilot and that terrain is unreasonably exact. For the record, I'm not experiencing any of these problems when the visibility is ~ 100 km - the terrain is simply gone. But I think it would be nice to have an option to switch off the default terrain, to replace it by something else. As I indicated in the Forum http://www.flightgear.org/forums/viewtopic.php?f=6t=12005 a solution to the problem would be to represent Earth from high altitude by pieces of a hires textured sphere (textures to be obtained from Celestia), with (at least as demo) a simple Nasal script controlling which pieces of the sphere are currently to be loaded. I did some experiments with a textured sphere and found that I can't simply place an Earth-sized sphere at the coordinate origin - the model is apparently deemed to be too far away and isn't shown. Maybe there is a simple way to switch this off - but if not, a viable solution would be to use a nearer (co-moving) sphere bit which is kept in the precise proportion to the real thing as given by simple ray optics. Using this trick, I have managed to get a plausible ufo-above-Earth view within 35 minutes work with a simple lowres (4096x4096) textured Earth. I believe all this is doable without significant modifications to the core. It may not be an elegant solution, but it can be picked up by anyone who is able to code a bit Nasal and can texture a model. Admittedly there are much more elegant solutions, and solutions which generalize to flights in the whole solar system, but I don't really see us getting started on that. Cheers, * Thorsten -- 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] Object distance fading color
I've recently done a visual comparison between hires Flightgear scenery and reality - for those interested, see here: http://www.flightgear.org/forums/viewtopic.php?f=5t=12259 One of the striking points is that in reality even in partially clouded skies distant objects do not start to fade into white (as the Flightgear terrain shader assumes) but into darker colors, sometimes providing a striking contrast with the horizon sky color before they fade into the horizon color at even larger distance. I've played a bit with /rendering/scene/saturation to see if there was a way to recover that, but it didn't seem to do the right thing. I believe the relevant parameter is the amount of light reaching the surface at a given altitude. Naturally, the terrain shader can't know that up front, but the weather system has all the the information needed. If anyone is interested in attacking that problem from the shader side by exposing a property which can dial the 'darkness' of distant objects when they start to lose their color, I'd be happy to do my part from the weather side and cook up a model which sets the parameter value dependent on conditions. * Thorsten -- 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] Reparsing materials.xml runtime?
Following the idea of placing conditionals on position in materials.xml, I have created a rather nice demo for regional textures. But the problem remains that only the startup position counts, i.e. I suspect materials.xml is parsed only once during a Flightgear session. Is there a simple way to make the core re-read materials.xml at runtime, or can this be implemented without too much trouble? I think the general idea to represent a European city by a different texture than a US city is appealing (at least to me), but for people doing transatlantic flights a regional texture based on the startup location isn't so compelling. Cheers, * Thorsten -- 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] High altitute/speed flights terrain engine problems
As I indicated in the Forum http://www.flightgear.org/forums/viewtopic.php?f=6t=12005 a solution to the problem would be to represent Earth from high altitude by pieces of a hires textured sphere (textures to be obtained from Celestia), with (at least as demo) a simple Nasal script controlling which pieces of the sphere are currently to be loaded. As I said previously, it's gotta be implemented not on model level but on whole FG level, or not implemented at all. Think You have more productive computer while I have midproductive. We must orientate on users with midproductive or even less powerful computers. Current FG terrain engine can not be used on high altitude/speeds on current midlevel computers and gotta be switched off anyway. I did some experiments with a textured sphere and found that I can't simply place an Earth-sized sphere at the coordinate origin - the model is apparently deemed to be too far away and isn't shown. Maybe there is a simple way to switch this off - but if not, a viable solution would be to use a nearer (co-moving) sphere bit which is kept in the precise proportion to the real thing as given by simple ray optics. Using this trick, I have managed to get a plausible ufo-above-Earth view within 35 minutes work with a simple lowres (4096x4096) textured Earth. Well, I suppose there is possible solution, as rising LOD of whole model and LOD of Earth in model xml file. animation typerange/type min-m0/min-m max-m100/max-m /animation But what will You do in multiplayer? I believe all this is doable without significant modifications to the core. It may not be an elegant solution, but it can be picked up by anyone who is able to code a bit Nasal and can texture a model. Admittedly there are much more elegant solutions, and solutions which generalize to flights in the whole solar system, but I don't really see us getting started on that. Again, in multiplayer You'll cover sky of other users with giant sphere or will look as craft with big sphere aside for others. It's not only not elegant, it's not solved problem really. Of course it possible to make mutiplayer model without that sphere and so on, but normal things gotta be common. Otherwise it makes problems what can not be solved. Cheers, * Thorsten Cheers, * Victor -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object distance fading color
On Wed, 2011-06-01 at 14:50 +0300, thorsten.i.r...@jyu.fi wrote: I've recently done a visual comparison between hires Flightgear scenery and reality - for those interested, see here: http://www.flightgear.org/forums/viewtopic.php?f=5t=12259 One of the striking points is that in reality even in partially clouded skies distant objects do not start to fade into white (as the Flightgear terrain shader assumes) but into darker colors, sometimes providing a striking contrast with the horizon sky color before they fade into the horizon color at even larger distance. I've played a bit with /rendering/scene/saturation to see if there was a way to recover that, but it didn't seem to do the right thing. I believe the relevant parameter is the amount of light reaching the surface at a given altitude. Naturally, the terrain shader can't know that up front, but the weather system has all the the information needed. If anyone is interested in attacking that problem from the shader side by exposing a property which can dial the 'darkness' of distant objects when they start to lose their color, I'd be happy to do my part from the weather side and cook up a model which sets the parameter value dependent on conditions. Part of the problem is that FlightGear almost always renders ideal situations for the skydome. If you look at this picture you see there are situations where white fog is natural: http://upload.wikimedia.org/wikipedia/commons/2/2a/St.Gilgen_Panorama_2007-02-22.jpg But you obviously won't get that with the sun hidden behind a cloudy sky. Erik -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgdata merge requests.
Greetings fgdata committers, I notice that there is 4 outstanding merge requests for fgdata master branch in git (including one that belongs to me). It also looks like gitorious.org have changed their merge procedure so it works much better now, which is good news. Can some folks have a look at committing some of these please. cheers S. -- 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)
On Tuesday, May 31, 2011 03:02:09 PM Vivian Meazza wrote: 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 should have been clearer - Sorry. What I was trying to say is that we shouldn't need special cases to include this type of stuff in the rating. 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? These add a lot. I treated them as systems and included them in Systems rating. Seemed like the right way to handle this stuff to me. 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. I agree with this (IE. that liveries only make sense for some models). Stuart changed the External Model category to make liveries optional to get a 4 or above. The P-51 is a superb model already, and at a reasonable frame rate here - about 75% of my benchmark figure. The yasim p51d gets about 35 FPS on my older system (it's probably a mid level system by todays standards) and the jsbsim version gets about 22 FPS under the same conditions. Considering how much more detail there is in the JSBSim cockpit I think it does OK frame rate wise. It would benefit from a tutorial on the start procedure - It does have a complete startup check list/procedure in the aircraft specific help that is basically copied from the pilots manual. The startup is fairly simple (comparable to a single engine GA aircraft) so most users should be able to get it running by reading the startup check list/procedure. but apparently that would win no points either. That seems to be a missed opportunity too. I agree that the quality of the aircraft specific help and the existence of tutorials needs to be factored into the rating system some how. I suppose the P-51 FDM is accurate - but I find it not all that pleasant to fly. There is a high pilot work load during take off and initial climb out and this makes things unpleasant during those part of a flight. Once up to or above normal climb speed and trimmed it becomes fairly easy to fly. It also can be a handful in high G maneuvers since it will snap if there is a yaw angle as you approach stall. You can appoach stall at fairly high speeds in high G maneuvers without blacking out. FG pilots will likely find this behavior surprising since the JSBSim P-51D is the only FG aircraft I know of that will do this. But after the pilot gets used to this behavior it gives the pilot a level of feedback near stall that is very useful. I would say that you have probably slightly underrated its score. I may have been overly critical with my ranking but I have a very long todo list and I am acutely aware of how much work remains to be done. I think this is a common situation among those who are trying to create very high quality models and I also believe that most individuals trying to create high quality models will tend to underrate their own models. I think this is a good thing since it sets a very high bar. 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. This I don't totally agree with. The system is far from perfect but at least we have a documented rating system that is somewhat objective and fairly easy to do. We can improve on it going forward to make it more complete and what we have now is a good starting place and is clearly better than the wet finger in the air method. 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. I think these are separate issues from rating model maturity. 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] Rating System Redux (was Re:Flightgear-devel Digest, Vol 61, Issue 12)
On Tuesday, May 31, 2011 10:26:18 PM Robert wrote: 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. I think how much compute power is needed and how difficult a model is to use/fly are seperate subjects from the status/maturatity of the model. In general models that are more mature will tend to require more compute resources and also will be more difficult to use/fly for aircraft of similar complexity IRL. Ease of use of the models should reflect how difficult the aircraft is to fly IRL at least for mature models. New users, particularly younger ones, sometimes think that FG is a game rather than a simulation and assume that how it presents aircraft should be arcade game like. I have seen a number of forum threads that started off with something along the lines of I just started using FG today and I tried to fly complex high performance aircraft and I always crash during take off Invariably the next post will point out that complex high performance aircraft requires a lot of skill and experience to fly and will ask the user if he has tried the C172P or some other basic aircraft. The OP will reply no but I will. Then they report that they were succesful with the more basic aircraft and are happy with FG. IRL you don't climb into the pilots seat of a complex high performance aircraft for your first flight ever and expect to walk away in one piece. Why would this be different for FG and why would FG users expect it to be different? Having a difficulty rating someplace visible to users is a good idea since it might clue in at least some new users that they probably need to start out with something easy to fly usless they fly complex aircraft IRL. So I agree ratings for difficulty of use and how much compute power is needed should be seperate from the status since these have nothing to do with model maturity. 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! The overall status is for backward compatibility. It is displayed in fgrun and on the download page already. Also the most mature models will have eye candy, complex system modeling and a high quality FDM. So I think it does tell most of the story and users can infer how much compute power is needed for a given level of real life aricraft complexity from the status rating. A very simple aircraft (IE. Piper Cub or sail plane) of any status probably will run fine on a low to mid level system. But a highly complex aircraft that has a mature model (production or above) will probably require a high end machine to get good frame rates. It's not really rocket science as it just requires some common sense to figure out. But I don't see any reason not to also include information about required compute power for each model. But the idea of showing the user individual scores (FDM, Systems, Cockpit, 3d model, + needed resources) is a good one! What do you think? At this point users have to look in the XML files to see the FDM, Systems, Cockpit and External model scores. These are not visible in any UI or on the download page. So at this point only users who understand how things are setup in FG will be able to find this information and more work will be needed to make it available to nave users. Another issue is for the needed resources and difficulty rating to make sense there needs to be documentation on how to create the ratings and a description some place for user so that they can understand what these mean. 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
[Flightgear-devel] Linker failed to build fgfs
Hi all, with the last commit from James Turner I could not build FGFS on Linux. Now with a fix from Frederic, I can compile but still not link. Here is what I got: http://pastebin.com/Xye7VeWr g++ (Debian 4.6.0-6) 4.6.1 20110428 (prerelease) Regards, Roland signature.asc Description: This is a digitally signed message part -- 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] Linker failed to build fgfs
On 01.06.2011 20:48, Roland Häder wrote: with the last commit from James Turner I could not build FGFS on Linux. Fixed now. Friends of CMake forgot about automake... ;-) cheers, Thorsten -- 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: - Original Message - 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 I was trying to compile the SimGear-2.0.0 sources from http://simgear.sourceforge.net/. As mentioned, the git sources compile using Cmake 2.8.4 and OSG 2.8.4 (after some minor tweaking of the 3rdParty dependencies). Thanks to everyone who contributed, I would have given up without you :) Cheers, 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] Rating System Redux (was Re:Flightgear-devel Digest, Vol 61, Issue 12)
Adding to Hal's comments: On Wed, Jun 1, 2011 at 7:21 PM, Hal V. Engel wrote: On Tuesday, May 31, 2011 03:02:09 PM Vivian Meazza wrote: 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? These add a lot. I treated them as systems and included them in Systems rating. Seemed like the right way to handle this stuff to me. Yes - these are now covered by the Systems rating, which feels like a much better place than my original suggestion of External Model. 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 agree that the quality of the aircraft specific help and the existence of tutorials needs to be factored into the rating system some how. I was having a think about this myself today. I don't think having a tutorial is critical for a particular rating, but I do think that the start procedure should be documented in-sim, either in the aircraft help or as a tutorial. Accurate startup procedure is already a criteria for a System:3 rating. I propose that we change this to read Accurate startup procedure, documented in-sim (aircraft help or tutorial) Does that sound sufficient? Of course, this doesn't cover all the other procedures that we might want documented, but it is common to all (powered) aircraft. 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. This I don't totally agree with. The system is far from perfect but at least we have a documented rating system that is somewhat objective and fairly easy to do. We can improve on it going forward to make it more complete and what we have now is a good starting place and is clearly better than the wet finger in the air method. I think this is certainly a step in the right direction. The system isn't perfect, and I'm sure there are some aircraft that will end up under-rated and some over-rated, but it will certainly sort the wheat from the chaff and give new users and idea of what to expect from a given aircraft. If a new user looks at early production aircraft, they should get a very good impression of the quality available from FG. The perfect is the enemy of the good. - Voltaire (but A witty saying proves nothing. - Voltaire) -Stuart -- 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 McLane wrote: 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... Hi, while i can't give you the exact output that I reported, right now (i'm not on my Computer where it happened), I have dug a bit deeper into the rlimit stuff. I used TG with the following patch applied (partly strange): http://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=blob;f=games- util/terragear-cs/files/terragear-cs- setrlimit.patch;h=bcb166cd1c6311d655416c4aacefa1b71bcd25c4;hb=e330979f290cc3b2259f124ddc9d9527d42280c5 To rule out any influence of it, I built TG without it, but the fgfs- construct process got interrupted very early, even with a small part of scenery to build. So it seems like this patch is needed one or the other way. Maybe with other settings. What do you use there? 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
