Re: [Flightgear-devel] FG 2.4 consistency
On Wed, 2011-07-13 at 15:24 +0200, grth_team wrote: FG 2.4 consistency. Hello, You don't know us since we are newbee, (3 months working seriously with FG). We are a team ( 4 guys and a lady ). We have had several talks with several devel team persons about a Catalina model update. That update has been rejected arguing that everything is frozen until FG 2.4 will be freed, considered consistent, without any bug. It's not so much rejected, but declined to be included in GIT. The current release process is quite new to all of us so there might come up some unforeseen problems. Clearly this is one of them. It's unfortunate since you've put so much work in it, but then remember; so have all of use (or at least the great majority has). Judging from this email it wasn't the intention just to drop your efforts with the flip of a switch but it just happens to be bad timing; if you could have offered it three weeks ago everything would have been fine. You are free to offer the model on your own (many aircraft developers to this for one reason or another) and I for one am pleased to see others to step up to improve upon our current aircraft. So I would advise to try to get it included just after the new release and then when the 2.6 release is in feature freeze you could still get bug fixes included (which are probably minor compared to a complete overhaul). To please to the users, our model will be ever checked against an FG stable version. We will start that rule with FG 2.4, offering our models within our pages, but, under an other license. I have tot state that it is not allowed to change the license unless: * everything you use is your own work * or you're moving to a more restrictive license that is still open source (which is hard in case of the GPL). Erik -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
You mentioned earlier that a lot of the performance issues would disappear if we could probe the terrain 100 times faster. I've been thinking about this for a while for ai traffic, skyop's moving map instrument, and weather. I'm thinking of storing some resolution of altitude data in the tile itself, making altitude queries very fast at the expense of a larger tile (in memory and disk). I'm just starting the work, but I would like any feedback on the idea. I can maybe tell you what I need. Currently, Local Weather uses terrain info in three ways: 1) a presampling routine gets gross features in the vicinity of the aircraft, i.e. mean altitude, median altitude, max. altitude,... That's now implemented by Torsten as C++ routine running in the background - I don't know details and don't know if it would benefit 2) convective clouds are placed based on both terrain type and elevation. For convective (not any other) clouds, there is extra work running for 2-30 seconds (dependent on number, terrain detail,...) in the background at the rate of ~12 geodinfo() calls per frame (geodinfo is a rather expensive operation - more than 25 per frame are simply out of the question). 3) for the 3rd generation cloud-terrain model currently under development, there's an additional need to probe elevation (but not terrain type) for many cloud types - curently using geodinfo() as well 2) and 3) are among the most computationally intensive processes Local Weather runs, simply because geodinfo() is expensive (though perhaps not the most garbage-collection triggering ones). If that could be made much faster, tile setup could be accelerated dramatically. I wouldn't actually need the exact altitude/terrain type at a given location for weather - an approximation which gets me some elevation and terrain type within, say, 100 m of the specified coordinates would be just as good, especially if it comes faster. If it really accelerates by a large margin, then it allows the setup of tiles to be essentially in a single frame, so one can really restart the system without the user noticing. Cheers, * Thorsten -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
Erik wrote On Wed, 2011-07-13 at 15:24 +0200, grth_team wrote: FG 2.4 consistency. Hello, You don't know us since we are newbee, (3 months working seriously with FG). We are a team ( 4 guys and a lady ). We have had several talks with several devel team persons about a Catalina model update. That update has been rejected arguing that everything is frozen until FG 2.4 will be freed, considered consistent, without any bug. It's not so much rejected, but declined to be included in GIT. The current release process is quite new to all of us so there might come up some unforeseen problems. Clearly this is one of them. It's unfortunate since you've put so much work in it, but then remember; so have all of use (or at least the great majority has). Judging from this email it wasn't the intention just to drop your efforts with the flip of a switch but it just happens to be bad timing; if you could have offered it three weeks ago everything would have been fine. You are free to offer the model on your own (many aircraft developers to this for one reason or another) and I for one am pleased to see others to step up to improve upon our current aircraft. So I would advise to try to get it included just after the new release and then when the 2.6 release is in feature freeze you could still get bug fixes included (which are probably minor compared to a complete overhaul). To please to the users, our model will be ever checked against an FG stable version. We will start that rule with FG 2.4, offering our models within our pages, but, under an other license. I have tot state that it is not allowed to change the license unless: * everything you use is your own work * or you're moving to a more restrictive license that is still open source (which is hard in case of the GPL). I have downloaded and compared the updated version released under CC and the GPL version in Git. It is a nice improvement in terms of detail, however, much of it is carried over verbatim or with minor updates from the GPL version. In particular this applies to the JSBSim config (author Ron Jenson) whose permission, I understand, has neither been sought nor given to this license change. I think that Ron, as the copyright holder, might be justified in pursuing this matter. It also uses some clever techniques which work in FG, but do not in FGRun. It also appears that there are 5 image files missing. It is therefore fortunate that this update has not been included in Git before the release of 2.4. Contrary to the claims made, the version in Git runs without error under Windows XP, and I see no reason why it should not under later Windows variants. It is in any case, highly unlikely that any aircraft in our inventory would run under Linux, but not under Windows. If there are known to be any - a proper bug report would be welcome, and not the vague hand waving which was purported to be a bug report by the grth-team. I would encourage the grth-team to get it right, and forward a proper Merge Request in Gitorious. Vivian -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Current Weather System...
If I may be permitted some personal comments about things which bug me? I've been thinking quite a bit (possibly more than it's good for me) triggered by responses on the list during the last days, and I would perhaps take the time to clarify my position on a few things. I get the impression that some people believe that Local Weather is a temporary, experimental thing. That's actually not my position. I assigned a version number larger than 1.0 because for me it is a stable, mature, well-performing system (running on a 3 year old Linux laptop) and no more or less experimental or temporary than the rest of Flightgear (which means it can always be better, but doesn't need to be so urgently). I haven't seen any serious bugs for more than 2 months, it has some quirks (rain textures sometimes not reaching all the way to the ground, problems when two thermals overlap, winds being slightly off METAR are the recent ones which come to my mind) - but I see quirks in many systems (the AP of a large number of aircraft, global weather producing rain for blue sky above, turning the view towards the rear in the F-16 introduces a 1 second lag,...). Judging by forum response, there are other people who use the system regularly as well instead of Global Weather and likewise don't have major problems. Now, based on what I get to read here, there seem to be issues on other machines. Largely, I can't fix these because there is not much machine-specific in Nasal - so what am I supposed to do? Also, that's hardly unique for weather or Nasal code - for instance, I can't use the landmass effect - with a quality setting below 3 or so, all I see is black - above 3 I get to see the relief effect, but I'm down to 5 fps. I have received something like an explanation by Emilian, but as far as I know it's not considered a bug which makes the shader effects an immature feature, but simply something I can't have because of hardware issues - and clearly not Nasal issue (otherwise, please fix...). Having said that, there are many issues of which I am aware, and they are part of the documentation http://www.phy.duke.edu/~trenk/files/README.local_weather.html sections 10 and 11 - I try to list each issue, explain where it arises from and what is planned for a fix or why in my current understanding it can't be fixed. In 4 out of 5 cases when I get problem feedback, the issue is listed there already... can occasionally be frustrating. I don't want to start bitching here, but I think that type of issue list actually not done by so many people. Another part of the reason that the system is considered immature seems to be that it is coded in Nasal. Now, it's a fact that C++ is in general faster and that complex heavy-duty Nasal code has issues with garbage collection which trigger single-frame delays. However, I think there is some dislike of Nasal involved which goes beyond what is covered by these facts. As for speed, my current best estimate is the comparison in performance between Torsten's hard coded terrainsampling and my Nasal version - his seems to be about a factor 3 faster. Which sounds a lot - until one realizes that the difference between efficient and inefficient code is usually way more. As an example, we're to all appearances currently calculating ridge lift in the core code on a per-frame basis sampling a series of terrain points along the windline even if the actual value of ridge lift is 10e-6 ft/s because we are 20.000 ft above every terrain feature (at least I get to see the value updated per frame) - isn't actually needed with that precision or sampling rate unless we are much lower and the loop could run every 100 frames at high altitude or sample just one terrain point - possible efficiency gain: factor 100 or more. Different example - the gradient terrain shader takes a lot of performance on my system - presumably because it computes a quantity (terrain gradient) on a per-frame basis which is actually constant across frames (?). Likewise, the dramatic difference in performance between Stuart's and my ways of moving clouds around has little to do with Nasal vs. C++ - largely, Stuart has found a much more efficient way to solve the problem, instead of moving 400 individual models, (as far as I understand) he combines the whole layer into a model and just moves that. It remains to be seen how we then fare when the need arises to introduce vertical movement of clouds - Stuart has provided a move operation, but that seems to teleports the cloud to a new location - so it must be applied on a per-frame basis again to get a smooth motion - which may deteriorate performance. But doesn't really spoil my point - efficient coding is the key. Nasal has a garbage collection problem. One solution to it is - we avoid Nasal code wherever possible and try to hard-code everything. But Nasal crops up on a lot of places - complex aircraft such as the Concorde come to my mind, interactive AI models, lots of really nifty and useful
Re: [Flightgear-devel] Current Weather System...
-Original Message- From: thorsten.i.r...@jyu.fi [mailto:thorsten.i.r...@jyu.fi] Sent: 14 July 2011 12:46 To: FlightGear developers discussions Subject: [Flightgear-devel] Current Weather System... If I may be permitted some personal comments about things which bug me? I've been thinking quite a bit (possibly more than it's good for me) triggered by responses on the list during the last days, and I would perhaps take the time to clarify my position on a few things. I get the impression that some people believe that Local Weather is a temporary, experimental thing. That's actually not my position. I assigned a version number larger than 1.0 because for me it is a stable, mature, well-performing system (running on a 3 year old Linux laptop) and no more or less experimental or temporary than the rest of Flightgear (which means it can always be better, but doesn't need to be so urgently). I haven't seen any serious bugs for more than 2 months, it has some quirks (rain textures sometimes not reaching all the way to the ground, problems when two thermals overlap, winds being slightly off METAR are the recent ones which come to my mind) - but I see quirks in many systems (the AP of a large number of aircraft, global weather producing rain for blue sky above, turning the view towards the rear in the F-16 introduces a 1 second lag,...). Judging by forum response, there are other people who use the system regularly as well instead of Global Weather and likewise don't have major problems. Now, based on what I get to read here, there seem to be issues on other machines. Largely, I can't fix these because there is not much machine-specific in Nasal - so what am I supposed to do? Also, that's hardly unique for weather or Nasal code - for instance, I can't use the landmass effect - with a quality setting below 3 or so, all I see is black - above 3 I get to see the relief effect, but I'm down to 5 fps. I have received something like an explanation by Emilian, but as far as I know it's not considered a bug which makes the shader effects an immature feature, but simply something I can't have because of hardware issues - and clearly not Nasal issue (otherwise, please fix...). Having said that, there are many issues of which I am aware, and they are part of the documentation http://www.phy.duke.edu/~trenk/files/README.local_weather.html sections 10 and 11 - I try to list each issue, explain where it arises from and what is planned for a fix or why in my current understanding it can't be fixed. In 4 out of 5 cases when I get problem feedback, the issue is listed there already... can occasionally be frustrating. I don't want to start bitching here, but I think that type of issue list actually not done by so many people. Another part of the reason that the system is considered immature seems to be that it is coded in Nasal. Now, it's a fact that C++ is in general faster and that complex heavy-duty Nasal code has issues with garbage collection which trigger single-frame delays. However, I think there is some dislike of Nasal involved which goes beyond what is covered by these facts. As for speed, my current best estimate is the comparison in performance between Torsten's hard coded terrainsampling and my Nasal version - his seems to be about a factor 3 faster. Which sounds a lot - until one realizes that the difference between efficient and inefficient code is usually way more. As an example, we're to all appearances currently calculating ridge lift in the core code on a per-frame basis sampling a series of terrain points along the windline even if the actual value of ridge lift is 10e-6 ft/s because we are 20.000 ft above every terrain feature (at least I get to see the value updated per frame) - isn't actually needed with that precision or sampling rate unless we are much lower and the loop could run every 100 frames at high altitude or sample just one terrain point - possible efficiency gain: factor 100 or more. Different example - the gradient terrain shader takes a lot of performance on my system - presumably because it computes a quantity (terrain gradient) on a per-frame basis which is actually constant across frames (?). Likewise, the dramatic difference in performance between Stuart's and my ways of moving clouds around has little to do with Nasal vs. C++ - largely, Stuart has found a much more efficient way to solve the problem, instead of moving 400 individual models, (as far as I understand) he combines the whole layer into a model and just moves that. It remains to be seen how we then fare when the need arises to introduce vertical movement of clouds - Stuart has provided a move operation, but that seems to teleports the cloud to a new location - so it must be applied on a per-frame basis again to get a smooth motion - which may deteriorate performance. But doesn't really spoil my point - efficient coding is
Re: [Flightgear-devel] Current Weather System...
On 14 Jul 2011, at 12:46, thorsten.i.r...@jyu.fi wrote: Nasal has a garbage collection problem. One solution to it is - we avoid Nasal code wherever possible and try to hard-code everything. But Nasal crops up on a lot of places - complex aircraft such as the Concorde come to my mind, interactive AI models, lots of really nifty and useful applications... - so instead of fixing things in a lot of places, one could also think about it the other way and fix just one thing, i.e. the garbage collection such that it doesn't hit a single frame. Indeed, and I've looked into this - it's a tough problem, but not an impossible one - and well contained - the current Nasal GC is a single source file. As you point out, the amount of scripted code is going to continue increase irrespective of local weather, so we need to bite the bullet sooner or later and fix the GC to be incremental. Fortunately, garbage collection is pretty well researched - the trick is finding an incremental algorithm that's 'simple enough' James -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Changelog for 2.4.0
Okay, it isn't plain text (we can easily convert it once it's done, altough I cannot think of a place where we'd publish a plain-text-changelog, apparently we stopped updating the fgdata/NEWS file), but this will allow us to work together on a nice release announcement/changelog, so nothing important is missed and everything is stated correctly and properly spelled. Feel free to add/edit/remove http://wiki.flightgear.org/Changelog_2.4.0 -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Current Weather System...
Hi Thorsten, Thanks for writing. I've got a couple of comments. On Thu, Jul 14, 2011 at 12:46 PM, Thorsten Renk wrote: I get the impression that some people believe that Local Weather is a temporary, experimental thing. That's actually not my position. I assigned a version number larger than 1.0 because for me it is a stable, mature, well-performing system (running on a 3 year old Linux laptop) and no more or less experimental or temporary than the rest of Flightgear (which means it can always be better, but doesn't need to be so urgently). I think the one reason for this view is the level of integration with the FG core, where you've had to work hard to override the global weather system through no fault of your own. I think with better integration, the local weather package will feel much more part of the whole. The other aspect is usability/simplicity, which I think is the nub of the problem and where we disagree. The third issue that bugs me is the expectation of simplicity. Usually in Flightgear, it is just accepted that things can be complicated. Flightgear is not an arcade game, if I want to fly the P-51D, I have to learn how to takeoff, that's complicated. Nobody here asks to simplify the FDM so that everyone can take off. But somehow, for a weather GUI, we should be back to arcade mode where a mouse click and a single performance slider should be all it takes. I don't really understand why - the argument for me is still the same - we're trying to be a realistic simulation, weather in reality is complicated, so why do you expect arcade-game like configuration? I think that comparison is flawed, as a user starts FG with the intention of simulating aircraft in flight, and weather simulation is really a secondary consideration. I think if it is possible and sensible to simplify the configuration, we should do so. In fact, weather is so complicated that if we introduce more and more realism one has to make a choice what to focus on (dependent on available performance, that can be a hard choice or not) - the system isn't designed to run in 'one mode fits all', it's designed to commit resources to what is most important, given the type of flight you plan. As an example, when I fly airliners, I'm not interested in simulating cloud movement (doesn't show with 250+ kt airspeed anyway) or thermals (do not occur at 30.000 ft) - but I am interested in seeing clouds as far out as possible (because that's what I see from 30.000 ft). I move my sliders accordingly. When I fly a glider, I'm very interested in thermals, moving clouds (thermals and cap clouds must move with the wind, otherwise the experience isn't very realistic) - but I am not interested in large visibility range, since I'm pretty much level with the convective layer anyway - so I do the configuration drastically different. If you take a moment to think about these issues, a system can't make the choice for you automatically, because it depends on what kind of flight you want to make. So you have to do it yourself. Or get a system that is so scaled down in performance that it gives you the minimal 'one fits all'. On the contrary, I think the two examples you give suggest a very simple heuristic, which is to decrease the resolution of the weather model as speed or altitude increases. I think this could be combined with a performance/quality slider in a similar way to the shader slider. As you say in your documentation, a number of the features (dynamic weather, thermals) are only really of interest to those flying low and slow. It seems applying two different measures to me to widely accept that aircraft systems can be very complicated and that people need to read a manual to start the engines, but to expect that an (optional!) weather system is simple to configure and yet delivers best performance. Being very blunt, this is after all primarily a _flight_ simulator rather than a _weather_ simulator. ;) As Vivian has mentioned, people don't read the normal manual, and the Local Weather configuration really does require close reading of the documentation. As it stands, most users will not read the documentation, and will struggle to enable and effectively use this feature. I think that is a great shame, as it provides a much more interesting weather environment than the global alternative. IMO, by making some design decisions we can simplify the interface, provide users with the right balance of performance and quality without requiring that they tune every last parameter, and increase the number of people who can make use of this feature massively. I think that is something that is worth working towards, and I am very happy to lend a hand to help achieve this. -Stuart -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup
[Flightgear-devel] Kulula Airways RSA
Hi there, My partner (works for Virgin Australia) got an email of photos of new liveries for this low-cost South African carrier, here is a link to some... http://www.iloveplanes.com/aviation-news/commercial/special-sxswi-edition-saturday-wings-kulula/ Brilliant! Well worthy of an addition or 2 to the 737 livery set perhaps? :-) Kind regards, Chris Wilkinson, YBBN/BNE.-- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Current Weather System...
Simple: Keep the options in the dialog simple, but add a advanced button, so everyone will be happy with the dialog! :D -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Changelog for 2.4.0
On Thu, Jul 14, 2011 at 10:22 PM, Gijs de Rooy wrote: Okay, it isn't plain text (we can easily convert it once it's done, altough I cannot think of a place where we'd publish a plain-text-changelog, apparently we stopped updating the fgdata/NEWS file), but this will allow us to work together on a nice release announcement/changelog, so nothing important is missed and everything is stated correctly and properly spelled. Feel free to add/edit/remove http://wiki.flightgear.org/Changelog_2.4.0 Good work Gijs. It's been such a long time since the last release, I had to look a the v2.0.0 changelog to check what was new! In looking at the last changelog, we mentioned shader support, so I think we might want to de-emphasise it slightly. There have been significant developments in that area, but shaders themselves are not new. I've added native multiscreen support. I think there are a couple of items currently on the list that are fairly minor, and detract from some of the major improvements that have happened. I'd suggest that they are removed, but didn't want to remove them without comment: Aircraft operations: - Indicated airspeed (IAS) limitations can be indicated on the airspeed indicator - Surely this is a straightforward model improvement rather than a new feature? - Improved autopilots - Seems a duplicate of Wind-up prevention on simple autopilot systems - A new head-up display (HUD) system - is this really new? AI Traffic - should these be included in Scenery Improvements? Navigation: - Autopilots can be driven by NAV or GPS instruments - surely this isn't new? I suspect this refers to a particular aircraft -Stuart -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Calling more than one AI scenario AT GPS location
Dear forum, Could someone tell me how to CALL into action another AI scenario for example see below! AI Scenario_1 runs, at some point during the scenario CALL to AI Scenario_2 ; to RUN (similar to a batch file CALL) Is this possible? I need to be able to run several scenarios WHEN an Aircraft or CARRIER vehicle has reached a certain GPS location. OR if needed to be loaded at flightgear startup, Initiate the next scenario when called !!! Kind Regards, Michelle __ This email has been scanned by Netintelligence http://www.netintelligence.com/email -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Current Weather System...
I think the one reason for this view is the level of integration with the FG core, where you've had to work hard to override the global weather system through no fault of your own. I think with better integration, the local weather package will feel much more part of the whole. I moved many computations out of the c++ core into XML configuration files, so we already should have enough points to hook into, but if there are any more things to do to open up the core weather system, I'm happy to do so. I think that is something that is worth working towards, and I am very happy to lend a hand to help achieve this. +1 Torsten -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
