Re: [Flightgear-devel] Nasal alternatives : possible, of course,
Ncolas, I didn't want to comment on your first post, everyone has a bad day sometimes, but here I like to add my 2 ct anyway. Am Mittwoch, den 04.03.2009, 17:52 -0500 schrieb Nicolas Quijano: > In the interest of clarity, moving to OSG was a good, if not brilliant > move (some potential sources of revenue would have it as a requirement > as far as open source engines are concerned) > It's simply a bit bloated, by default, although I suspect you don't > have to ship the parts you don't use at runtime to your users. > But it covers many bases and use cases of scene management and > rendering, so the bloat is offset by a generic and broad ability to > fill one's needs. > > Just wanted to clarify that I was not saying in any way that moving to > OSG was bad. It did leave previous users in its midst. > Rather, it's an example of how FGFS has been shown to be able to go > through titanic upheavals, a good trait of character :) > > > And switching to OSG wasn't a lot of work for very little > return for a sizeable portion of your (former) userbase ? > That a lot of features, some obvious, some not, are still not > working is not a hit on the ROI in your opinion ? > You talk of bloat, but you moved to OSG, the ultimate bloated > whale in the world of 3d rendering !! (and that's common > knowledge) > This is not a judgement on its quality btw, but it's bloated > software nonetheless :) > --paragraph break should have been inserted here > > > And I won't mention that is has no adequate documentation and > no debugger. Period. (<-- that's very serious) > Oops, sorry I just did ;) > > The last two lines talk about Nasal. > NOT OSG : it's documented and easily debuggable in one's favorite > development environment. > It also now has, among others, built-in Lua support ;) > I'm a simple content contributor with very little background in programming. When I made my first Aircraft (the bf109) I was confronted with the need to deploy slats automatically at a given speed. I din't want to embed C++ code or had such a complex script that the error messages in FG wouldn't help me and I previously only used a bit of python. I looked at some Nasal scripts and within a few hours it worked. I was impressed how easy it is to write even complex Nasal scripts. Later I started developing the walker feature that made it possible to walk around in the scenery, all with nasal. Stuart kindly enhanced the walker and added an animation system to it (see bluebird), again with nasal. Others have made Flight computers with it (see V-22 and Su-37). Nasal is a worthy tool and you gave no proof that Lua can do the same. Given the fact that FG is platform independant I don't know if the embedded C++ is doing the same on Windows, Linux, PPC and intel Macs. ( apart from the fact that if I was able to code c++ I would embed it to FG rather than in an Aircraft specific script). A lack of documentation may be the case, but on this list are a lot of friendly people helping out. Maybe there hasn't been a lot of praise for nasal, but I guess the broad use of nasal, even among JSBSim developers speaks for itself. As far as I know there hasn't been any comments of lacking nasal features (that weren't added within a short time). Finally: I _like_ Nasal! > Cheers, > Nic > > -- > Be Kind. > Remember, everyone is fighting a hard battle. > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel Greetings -- Detlef Faber http://www.sol2500.net/flightgear -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal alternatives : possible, of course,
In the interest of clarity, moving to OSG was a good, if not brilliant move (some potential sources of revenue would have it as a requirement as far as open source engines are concerned) It's simply a bit bloated, by default, although I suspect you don't have to ship the parts you don't use at runtime to your users. But it covers many bases and use cases of scene management and rendering, so the bloat is offset by a generic and broad ability to fill one's needs. Just wanted to clarify that I was not saying in any way that moving to OSG was bad. It did leave previous users in its midst. Rather, it's an example of how FGFS has been shown to be able to go through titanic upheavals, a good trait of character :) And switching to OSG wasn't a lot of work for very little return for a > sizeable portion of your (former) userbase ? > That a lot of features, some obvious, some not, are still not working is > not a hit on the ROI in your opinion ? > You talk of bloat, but you moved to OSG, the ultimate bloated whale in the > world of 3d rendering !! (and that's common knowledge) > This is not a judgement on its quality btw, but it's bloated software > nonetheless :) > --paragraph break should have been inserted here > > And I won't mention that is has no adequate documentation and no debugger. > Period. (<-- that's very serious) > Oops, sorry I just did ;) The last two lines talk about Nasal. NOT OSG : it's documented and easily debuggable in one's favorite development environment. It also now has, among others, built-in Lua support ;) Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal alternatives : possible, of course,
Howdy all, took my sweet time answering, and will not discuss this further on the list. I didn't want to start such a conversation, and consequently only answering now, at the risk of seeing another polemic start : not answering could give the wrong impression :) On Fri, Feb 27, 2009 at 12:40 PM, Brisa Francesco < > france...@brisa.homelinux.net> wrote: > just a minor curiosity: > what are the advantages of using LUA instead of Nasal ? > > Cheers > Francesco That's something you'll have to figure mostly out for yourself, as I really didn't want to get into that kind of argument (language comparisons, etc) because Lua tends to be come ahead in those when you mention brilliant, small and efficient in the same sentence : lua.org But off the cuff, and without getting into the internals, as I wouldn't (yet) be able to really give Nasal a fair shake : Documentation, debuggers, user community. Plus side effect of having a C API that allows loading of C/C++ modules through Lua (similar to python dlls) : that's a free, runtime usable plug-in system. If you don't see how this could be useful, well, think harder :) And you don't have to buy in the Lua way, there is no such way really, unlike Python and other scripting languages where the proper way to embed is embedding your app in the language and not embedding the language in your app. Lua embeds itself, like you want it to :) It's also brilliant, smaller (runs on cellphones) and faster than nasal (that's an opinion, but I really can't see how anyone says Nasal is fast, at least from my experience so far) I also think that using a roll your own scripting solution was a mistake, and a serious block in the wider adoption of Flight Gear as a developer sandbox (since on this list, we won't pretend it's a general public game, right ? ;)) It made me turn away a couple years back : an end user developer doesn't want to have to read source code to get started. In the game biz, it's never the best solution to roll your own when you can reuse, especially regarding scripting. Adequate solution, sometimes. Reinventing the wheel in a project that already relies so much on third party libraries simply makes no sense from an outsider's perspective, as it takes away precious and spare manpower from the crucial bits of the system And no, nasal is not really crucial, at least not with jsbsim. Why was Nasal chosen in the first place ? Wasn't it to supplement a fledgling FDM module at the time, yasim, that was lagging behind jsbsim and its property system ? Or so I've inferred and been told :) And then it grew from there... And well, as you can see already with FGFS and nasal, users have a way of misusing the tools you give them... Proper documentation is one step in that losing fight, a real debugger another : yes, always a losing fight to prevent user abuse, that doesn't mean nothing has to be done about it... Also, maybe unbeknownst to the authors, Nasal is really reinventing the Lua wheel in many cases :) Syntax has enough similarities that extensions to the Lua VM to execute Nasal as Lua bytecode is in the doable. var becomes local (Lua uses globals by default, local variables are specified by using local) Any left handed value can be hold anything Lua wise in it, be it the built-in types, user types, or light user types (only a pointer to user data accessed through Lua C Api) Oh, and you can compile your bytecode to C and load it as one of the aforementioned plug-ins as a first step of rolling back scripts into the native codebase for performance purposes... And Lua internals are really, really simple and mastered by a good portion of its community. Nasal simply doesn't compete at that level : community of users is far from critical mass, documentation is inexistent, and performance is not a priority, according to the author's own words on Nasal's site. The whole property tree would be accessed through the Lua C api, mapping to the same names inside Lua, and could be protected from writing from Lua, etc. Again, Lua is naturally meant to be a sandbox : it started as a purely configuration file parser and loader, and organically evolved over the last 15 years into a full fledged bytecode VM based language. It also doesn't impose coding styles, is naturally sandboxed. Research it, you'll come away a changed man ;) (kidding, you might not like it, but I'd be surprised anyone seriously researching it wouldn't see some clear advantages to it) This isn't a really hard project, it's just very tedious for the most part : the hair pulling would be from the amount of partial or complete porting of nasal scripts. As others have said, thanks to the property system (thanks jsbsim), there is already an elegant mechanism to interact with the internals of the engine, so adding another scripting language is quite trivial. All things I had considered before mentioning the possibility of Lua. And right after the first official release of OSG version would seem the right time for a ma
Re: [Flightgear-devel] SimGear and TerraGear CVS Browsing Links Broken
Geoff McLane wrote: > 1. Is CVS TG being fully abandoned? It depends on whom you ask :-) In fact, patch submissions against TerraGear CVS not getting processed for about 10 months finally led to the creation of the 'terragear-cs' GIT repository. Thus, CVS is nowadays approx. 2 years behind in development. > 2. What about CVS SG? Is this also 'dying' in favor of git simgear-cs 'simgear-cs' started as an adaption of SimGear CVS to allow for headless use of TerraGear, without requiring the presence of any $DISPLAY. 'simgear-cs' is meant to catch up with Simgear CVS occasionally and _should_ allow to build FlightGear, yet it's a bit dated today. This somewhat undefined state is mostly due to the fact that so far no decision wrt. an official GIT repository/mirror has been issued. > Sorry if I am the last person on the block to catch up ;=)) Don't worry, for the past years almost nobody has shown interest in TerraGear development, thus no discussion has taken place either :-) This discussion just surfaced after Frederic came up and with and started advertizing his Win32 port. Congratulations to Frederic ! Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] SimGear and TerraGear CVS Browsing Links Broken
The TerraGear page - http://www.terragear.org/cvs.html shows a link for 'Interactive CVS log browsing' as - http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/?root=TerraGear-0.0 But this is wrong. Through guess work I think it should be - http://cvs.terragear.org/viewvc/?root=TerraGear Likewise the SimGear page - http://www.simgear.org/cvs.html shows - http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/?root=SimGear-0.3 But guess it should be - http://cvs.simgear.org/viewvc/?root=SimGear Or maybe the flightgear cgi-bin/viewvc/viewvc.cgi could be corrected to go to the correct pages... Perhaps someone with access could check these pages... But I just checked out the CVS TerraGear source, and started to try to compile it in Ubuntu, but there are _MANY_ things broken!!! Starting with configure.ac! Maybe I missed some discussion where we are ABANDONING the TG CVS source fully in favor of the git repository... The CVS TG source still has things like - #include STL_STRING, and SG_USING_STD(string); BUT these macros have now been REMOVED from SimGear compiler.h... Browsing the SG CVS shows the last of these was removed some 7 months ago by Erik (ehofman) ... I remember reading some discussion about it on the board, but at the time was NOT trying to play with TG, and all the fixes have been done in FlightGear ... so thought little of it... So, again - 1. Is CVS TG being fully abandoned? 2. What about CVS SG? Is this also 'dying' in favor of git simgear-cs Maybe someone could just point me to the discussion, decisions, ... Sorry if I am the last person on the block to catch up ;=)) There is no 'complaint' here - just trying to understand, and that will also influence what I try to do in WIN32 also... Thanks and regards, Geoff. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
