From: Nicolas Q. <nqu...@gm...> - 2009-02-26 21:05:28
|
Hi all, let me start that my goal here is NOT to start a polemic on the reasons for using nasal vs any other scripting language, or the scripting vs native code, or any such argument :) Thanks for remembering that. That said, being a long time user and proponent of levering scripting in games/sims, and particularly, using Lua, I have a keen interest in any insights garnered over time by current and past fgfs devs. How coupled are Nasal and the scripting glue in FGFS ? Is there a clean break, or if not, can it be refactored without too much pain into something that would allow end dev users to use whatever scripting language they prefer, or have many modules already writen in, etc. If the coupling is not of the hair pulling type, it might be conceivable to integrate another scripting language alongside Nasal for starters, and in time, completely replace it if one is so inclined :) For me, this would be Lua, and I'll be working on integrating it in my local fork, but as I'm just getting down to tinker with FGFS source code, I'm interested in hearing your views on the topic. If there is interest in this beyond my own, I'd rather do it in a collaborative/friendly way that's not one sided, or in other words, I'd rather not rip out Nasal savagely to replace it completely with Lua, without thinking about compatibility down the road. My preferred approach would be to start with cohabitation, rather than coupling Lua to a local fork... What I'm interested in hearing is about the collective and individual experience of working with Nasal at the source code level, the API/communication mechanism between its VM/interpreter and "native" code, and plenty of other documentation details which do not seem to exist or that I haven't been able to find, and can save a lot of time in coming to grasp with code you haven't written. Thanks in advance for sharing your experiences with Nasal integration, Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. |
From: Ron J. <wi...@je...> - 2009-02-26 23:48:13
|
On Thu, 2009-02-26 at 16:05 -0500, Nicolas Quijano wrote: > Hi all, let me start that my goal here is NOT to start a polemic on > the reasons for using nasal vs any other scripting language, or the > scripting vs native code, or any such argument :) > Thanks for remembering that. OK, without getting into a religious discussion about the worth or advisability of adding another scripting into flightgear, it sounds like a lot of work and feature bloat for very, very little return. :) > That said, being a long time user and proponent of levering scripting > in games/sims, and particularly, using Lua, I have a keen interest in > any insights garnered over time by current and past fgfs devs. > How coupled are Nasal and the scripting glue in FGFS ? Is there a > clean break, or if not, can it be refactored without too much pain > into something that would allow end dev users to use whatever > scripting language they prefer, or have many modules already writen > in, etc. > > If the coupling is not of the hair pulling type, it might be > conceivable to integrate another scripting language alongside Nasal > for starters, and in time, completely replace it if one is so > inclined :) It may not be inconceivably hard to add another interpreted language to flightgear. The first problem I noticed today is our XML spec didn't have this in mind, we have: <nasal> <script> ... (code goes here )... </script> </nasal> So I suppose a <lua> tag wouldn't be bad... But if we wanted to go in the direction of adding support for random scripting languages we might want to replace the top level tag with something else: <userscript> <language="nasal"> <script> ... (code goes here )... </script> </userscript> or: <userscript language="nasal"> <script> ... (code goes here )... </script> </userscript> or even overload the current nasal tag to allow other languages: <nasal language="lua"> <script> ... (code goes here )... </script> </nasal> As far as replacing nasal, that project would be very hard. There are many vital parts of flightgear currently coded in nasal. There are also random bits of nasal code scattered around in joystick configurations, instrument and aircraft models, scenery models... everywhere. It would, in effect, require starting the whole data project over again. > For me, this would be Lua, and I'll be working on integrating it in my > local fork, but as I'm just getting down to tinker with FGFS source > code, I'm interested in hearing your views on the topic. If there is > interest in this beyond my own, I'd rather do it in a > collaborative/friendly way that's not one sided, or in other words, > I'd rather not rip out Nasal savagely to replace it completely with > Lua, without thinking about compatibility down the road. > My preferred approach would be to start with cohabitation, rather than > coupling Lua to a local fork... > > What I'm interested in hearing is about the collective and individual > experience of working with Nasal at the source code level, the > API/communication mechanism between its VM/interpreter and "native" > code, and plenty of other documentation details which do not seem to > exist or that I haven't been able to find, and can save a lot of time > in coming to grasp with code you haven't written. Nasal is actually implemented in the simgear project. Nasal "communicates" with flightgear through the property tree, so you'll have to create lua methods to read, write and create properties. Nasal calls flightgear commands in Main/fg_commands.cxx Nasal is also purposely limited on disk IO abilities. It is only able to read/write from specified directories. Otherwise it would be possible for a "rogue" aircraft script to send, say the contents of /etc/passwd to a random player on the multiplayer server... > Thanks in advance for sharing your experiences with Nasal > integration, > Cheers, > Nic > > -- > Be Kind. > Remember, everyone is fighting a hard battle. |
From: James S. <fli...@go...> - 2009-02-27 01:22:56
|
Nicolas Quijano wrote: > If the coupling is not of the hair pulling type, it might be > conceivable to integrate another scripting language alongside Nasal > for starters, and in time, completely replace it if one is so inclined :) At the risk of diverting the thread, and not wanting to get into religious argument, but I'm genuinely curious as to why would you even want to do this? Is there something that Lua (or any other language) can do that you can't do in Nasal? If there is, then it would probably be better to fix it in Nasal than it would be to embed a whole new scripting language. As Ron has indicated already, while it would be possible, you are talking an immense undertaking to "replace" Nasal, and it seems that there really isn't any actual return on that investment (not that this is necessarily a bad thing, plenty of things are done just for the hell of it). -- James Sleeman |
From: Melchior F. <mf...@ao...> - 2009-02-27 10:27:33
|
Adding another language wouldn't be that hard. Actually, we had another one before nasal and beside nasal for a while. It was called PSL (plib scripting language), and we ripped it out because Nasal was/is just better and because offering and maintaining two languages it utterly pointless . And that's why I consider the likeliness of getting lua or any other language support committed approximately zero. I for one would strongly oppose ("veto"-style :-). Of course, what you do in your private copy or fork is your business. m. |
From: Curtis O. <cur...@gm...> - 2009-02-27 14:27:59
|
On Fri, Feb 27, 2009 at 4:27 AM, Melchior FRANZ wrote: > Adding another language wouldn't be that hard. Actually, we had > another one before nasal and beside nasal for a while. It was > called PSL (plib scripting language), and we ripped it out because > Nasal was/is just better and because offering and maintaining two > languages it utterly pointless . > > And that's why I consider the likeliness of getting lua or any > other language support committed approximately zero. I for one > would strongly oppose ("veto"-style :-). Of course, what you do > in your private copy or fork is your business. Let me jump in with some pre-coffee comments (so I'm not yet responsible for anything I say) :-) Nasal is *very* well designed, compact, and efficient. It is used heavily throughout many areas of FlightGear. So I can't imagine any scenario where we would switch to some new scripting language unless a lot key developers were convinced that it was every so much better that that benefit would substantially outweigh the cost. And I find that scenario hard to imagine. I agree that if you want to play around with integrating Lua into your own development tree, that's great. You will learn a ton about flightgear and it's internal structures in the process. I tend to side with others that there would need to be some overwhelmingly compelling reason to support lua along side Nasal within FlightGear. If the primary motivation is language preference, that is going to be a really tough sell around here ... and that is because Nasal is *really* slick, brilliantly conceived, well implemented, and it has served us so well. But all that said, FlightGear is intended to be a developers sandbox, so please feel welcome to play and learn and ask questions. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ |
From: Martin S. <Mar...@mg...> - 2009-02-27 17:30:51
|
Hi Nicolas, for the sake of completeness it should probably be made clear that the person who's been trying to express strong emphasis against inclusion of another script interpreter is by no means in a position to issue a veto. The share of FlightGear developers who would like to see support for another scripting language in FlightGear - even though their preference might not be Lua - is (still) alive. They typically just don't have the habit of taking part in a discussion at the level it has reached in the meantime ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Brisa F. <fra...@br...> - 2009-02-27 17:40:31
|
just a minor curiosity: what are the advantages of using LUA instead of Nasal ? Cheers Francesco |
From: Nicolas Q. <nqu...@gm...> - 2009-03-04 17:54:25
|
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 < > fra...@br...> 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 major "spring" clean up of the codebase, etc since a lot of existing Nasal code is simply not working as advertised right now. With a will to add many widely different and not necessarily complementary features in FGFS, it's more urgent than ever than care be taken with performance, relative ease of use, etc. Or split it up in domain specific distros, a bit like SimGear is trying to do/doing at the "lower" level engine part. Witness : the last official release is extremely fragile when you start tinkering around and adding stuff not in the release itself... The share of FlightGear developers who would like to see support for > another scripting language in FlightGear - even though their preference > might not be Lua - is (still) alive. They typically just don't have the > habit of taking part in a discussion at the level it has reached in the > meantime ;-) > I fully understand that, and hence why I bothered to post, hoping to get some insights (thanks to those who tried) It's also why the word fork was mentioned. We're still evaluating things, and since our project and goals imply having fun doing it (not work, no commercial intent or defense contacts to seed financial support, just good old brain and wrist oil), it's up in the air whether we fork off FGFS and grow from there or use FGFS to bootstrap ourselves and build a custom simulator using jsbsim (with credit due where credit is due for inspiration) or any other possibility. This being developed as a purely "for fun" project, I want to avoid irritants :) I'm just floored by how far FGFS has come since the early days, as I regularly say, even more so when you take into account all the bickering and infighting that seems to take place within the developer core :) And the possibilities it offers : wide open. So naturally, I'm not only flying in it and preparing the Virtual Red Flag event, I'm evaluating it :) OK, without getting into a religious discussion about the worth or > advisability of adding another scripting into flightgear, it sounds like > a lot of work and feature bloat for very, very little return. :) > 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 :) And I won't mention that is has no adequate documentation and no debugger. Period. (<-- that's very serious) Oops, sorry I just did ;) All in good humour : thank you Ron for going beyond the knee jerk reaction, all in the same email. Thanks Martin and others who decided not to devolve into the kind of discussion I didn't want. In parting : it doesn't bother anyone that the overall feeling given by more than a few longstanding community members is that Nasal is NOT well liked, quite the contrary ? That's the overwhelming current I've felt. In fact, outside this list, I haven't heard much praise for Nasal. And I don't mean the windows using, non coder crowd that some of you really look down if not frown upon :) I mean some current and former core devs. I find it mind boggling that most of the dev info I've found so far has not been through the mailing list (archives are barely usable, so rely on google hits in the archives) or developer documentation, but from private discussions and sheer luck in searching for info. Someone mentioned that I should fix Nasal instead : I think it should be clear by now why I wouldn't do such a thing, when the same effort could be used to bring a fully documented, open source (permissive license), Eclipse and other IDEs integrated solution that has a few good debuggers into the fray. Fixing Nasal is not trivial, bringing in Lua is, replacing nasal completely would then be mostly tedious (and probably less so than simply fixing all the existing nasal scripts : porting gives you a reason to fix them at least...) Having debugged scripts while running the main exe in my IDE's debugger and ping ponging between the two code flows in many projects this decade, there is no way I'd invest myself in a language that doesn't come close to offering the standard features you'd expect from such a deeply ingrained part of a developer's sandbox. I'll use it if I have too, but I'll do my best to avoid it. And, maybe alas since it's contrary to some views expressed, I'm really not the only one who thinks that, as you darn well all know. I mentioned fork purposefully in my initial post as well as politely requesting an effort to maintain the discussion at a certain level. This failed, not that badly, but failed nonetheless. This is not the way to grow a community, and it's not for nothing I blew a gasket with Csaba/Jester the first time I posted on the forums : after reading archives, forum posts, etc. all full of that snide, elitist attitude exhibed by some, I jumped at the first sign of platform bigotry (platform agnostic myself) Sadly, I was completely wrong and Jester didn't deserve any recrimintations from me. Sorry in advance for saying all that, but you know it's true. Apologies to those who might feel slighted and have no business being so. That said, it would seem cliques and personal fiefdoms, and one's ability to veto changes or not, are more important than having more people use and develop the software. Like many others, I don't have time for that sort of thing, even though I manage to get sucked in once in a while ;) I hope I'm wrong, back to lurking. Hope no one is bored to death by the long "rant" Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. |
From: Andy R. <an...@pl...> - 2009-03-14 17:14:29
|
Oh, man -- giant Nasal flame war and I totally missed it. Melchior just now pointed me here. Sadly (or, well, not at all, actually) Andy's been doing a lot more of the daddy thing than the hacker thing recently. Some quick shots after the fact: Nicolas Quijano wrote: > 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) While Lua is pleasingly small, it's certainly not smaller than Nasal, either in code size or size of runtime data (especially at runtime: Lua lacks anything like the vector type Nasal has and can't represent packed arrays). And I also had Nasal running on various phones* back in 2004/5 when I was doing that stuff for my day job. [* Not, by the way, that phones are particularly "small" any more. Sure they can run Lua and Nasal: also Javascript, one or more JVMs, a .NET CLR interpreter, often a flash interpreter, bash, perl, python, VB, ...] As far as speed goes, the last time I was doing any benchmarking Nasal was about as fast as Perl 5 or Python 2.2 at most things. It's garbage collector was faster, its symbol lookup about the same or slightly faster, and its bytecode interpreter somewhat slower. I'm not aware of any FlightGear usage where Nasal's performance is an issue, but I'm willing to take bug reports. And I'm amused that you feel free to express an "opinion" about a quantitative subject. Either Nasal is or is not faster or smaller than Lua; I'm not sure what your opinion is coming from if not measurements. :) > And I won't mention that is has no adequate documentation and no > debugger. Period. (<-- that's very serious) If you say so. I've been writing script code in perl and python for a decade and a half and haven't ever felt the need to use a debugger in either environment. That's very much a taste thing. If you can't handle the need to call print() or write an if() to inspect or trigger on runtime state and want to type into a command window instead, that's cool. Just don't pretend that everyone feels the same way. The documentation thing sounds more like a cheap shot than a real complaint -- is there something you'd like to see documented that isn't? We don't have books on Nasal. We certainly do have docs. So as far as flames go, some stuff off the top of my head that was, I think, true at some point in the past. I'm not 100% confident on all this, because my Lua knowledge is pretty stale. + Nasal is threadsafe. Lua has a global interpreter lock. + Nasal is stackless for interpreted code. Lua recurses on the CPU stack. + Nasal is a true functional language, with lexical scoping, runtime binding and true closures. Lua has a clunky global namespace. + Nasal has complete programmatic control over the runtime namespace for any piece of code, making "modules" a question of script coding and allowing a bunch of neat metaprogramming tricks along the lines of what the Ruby folks do with their monkey patching. Take a look at the (non-FlightGear) Gtk library for some examples. Lua, again, has a clunky global namespace. + Nasal's data model matches what you are used to from perl, python and javascript. Lua's is ... odd. + Nasal has a true garbage collector. Lua has a reference counter that can't handle circular references. + Nasal has syntax that makes sense in the modern world and to programmers exposed to other languages like Javascript. Lua looks like PL/1. But hell, there's really nothing (other than cosmetics) wrong with Lua. As you mention, it's grown into a large community with lots of documentation and libraries and professional-looking trappings. None of that was true in 2003/4 when Nasal was in its infancy, but it is now, and I can see why it would be attractive. If you want to do the integration work and maintain it (remember, there's a ton of code outside the interpreter you need to write to be able to do useful things inside the simulator), feel free. > 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 Ooh, a YASim flame too. Bring it on. :) Andy |
From: Curtis O. <cur...@gm...> - 2009-03-14 18:40:09
|
This thread has been quite entertaining! A big thanks to all the participants!!! :-) Curt. On Sat, Mar 14, 2009 at 8:33 AM, Jon S. Berndt <jon...@co...>wrote: > > Oh, man -- giant Nasal flame war and I totally missed it. Melchior > > just now pointed me here. Sadly (or, well, not at all, actually) > > Andy's been doing a lot more of the daddy thing than the hacker thing > > recently. > > I kept up fairly well as a developer when we had two, but when we went from > two to four kids in one fell swoop, it was like the rocket sled hitting the > water trough. > > JB > > > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ |
From: syd a. <ada...@gm...> - 2009-03-14 20:50:29
|
I'll second that .... still waiting for page 3 ;) On Sat, Mar 14, 2009 at 11:40 AM, Curtis Olson <cur...@gm...> wrote: > This thread has been quite entertaining! A big thanks to all the > participants!!! :-) > > Curt. > > > > > On Sat, Mar 14, 2009 at 8:33 AM, Jon S. Berndt <jon...@co...>wrote: > >> > Oh, man -- giant Nasal flame war and I totally missed it. Melchior >> > just now pointed me here. Sadly (or, well, not at all, actually) >> > Andy's been doing a lot more of the daddy thing than the hacker thing >> > recently. >> >> I kept up fairly well as a developer when we had two, but when we went >> from >> two to four kids in one fell swoop, it was like the rocket sled hitting >> the >> water trough. >> >> JB >> >> >> >> >> ------------------------------------------------------------------------------ >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Flightgear-devel mailing list >> Fli...@li... >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel >> > > > > -- > Curtis Olson: http://baron.flightgear.org/~curt/<http://baron.flightgear.org/%7Ecurt/> > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > |
From: Robert B. <sim...@gm...> - 2009-03-14 23:46:53
|
I learned a lot just reading it. Curtis Olson wrote: > This thread has been quite entertaining! A big thanks to all the > participants!!! :-) > > Curt. > > |
From: Artem C. <art...@ar...> - 2009-02-27 18:09:56
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html><head><title></title> <META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <meta http-equiv="Content-Style-Type" content="text/css"> <style type="text/css"><!-- body { margin: 5px 5px 5px 5px; background-color: #ffffff; } /* ========== Text Styles ========== */ hr { color: #000000} body, table /* Normal text */ { font-size: 9pt; font-family: 'Courier New'; font-style: normal; font-weight: normal; color: #000000; text-decoration: none; } span.rvts1 /* Heading */ { font-size: 10pt; font-family: 'Arial'; font-weight: bold; color: #0000ff; } span.rvts2 /* Subheading */ { font-size: 10pt; font-family: 'Arial'; font-weight: bold; color: #000080; } span.rvts3 /* Keywords */ { font-size: 10pt; font-family: 'Arial'; font-style: italic; color: #800000; } a.rvts4, span.rvts4 /* Jump 1 */ { font-size: 10pt; font-family: 'Arial'; color: #008000; text-decoration: underline; } a.rvts5, span.rvts5 /* Jump 2 */ { font-size: 10pt; font-family: 'Arial'; color: #008000; text-decoration: underline; } /* ========== Para Styles ========== */ p,ul,ol /* Paragraph Style */ { text-align: left; text-indent: 0px; padding: 0px 0px 0px 0px; margin: 0px 0px 0px 0px; } .rvps1 /* Centered */ { text-align: center; } --></style> </head> <body> <p>Hello to everyone!</p> <p><br></p> <p>I'm Ph.D. student from Kiev, Ukraine and I'm studying ways and methods</p> <p>for developing acontrol systems on the basis of artificial neural networks approach. It's very interesting thing -- such control systems will be more familiar with human's brain organization and be able to teach on examples instead of having strong builted-in control laws.</p> <p><br></p> <p>FlightGear is a perfect testing area of control algorythms, because it is complex flight object. So, I need a way to connect to FlightGear, but I don't understand how to do this. </p> <p><br></p> <p>Genereally speaking, I need two things:</p> <p><br></p> <p>1) Obtain plain's position and rotation angles every moment by my program;</p> <p>2) Be able to control plane, i.e. to set elevator, elevator in some position instead of pushing the buttons.</p> <p><br></p> <p>I've heard that it is possible to control FlightGear via some "net_fdm binary data exchange protocol", and that it is even included in MATLAB for visualizing FlightGear. But didn't found any examples dedicated to this protocol.</p> <p><br></p> <p>Could you please advice? Any solution that can give me 1) and 2) would be great.</p> <p><br></p> <p>Good luck to all pilots,</p> <p> Artem Chernodub</p> <p><br></p> </body></html> |
From: Lee D. <du...@ra...> - 2009-02-27 18:25:02
|
Artem, You might want to consider using JSBSim instead of FlightGear. I think you'll find it a lot easier to work with. Lee Artem Chernodub wrote: > > Hello to everyone! > > > I'm Ph.D. student from Kiev, Ukraine and I'm studying ways and methods > > for developing acontrol systems on the basis of artificial neural > networks approach. It's very interesting thing -- such control systems > will be more familiar with human's brain organization and be able to > teach on examples instead of having strong builted-in control laws. > > > FlightGear is a perfect testing area of control algorythms, because it > is complex flight object. So, I need a way to connect to FlightGear, > but I don't understand how to do this. > > > Genereally speaking, I need two things: > > > 1) Obtain plain's position and rotation angles every moment by my program; > > 2) Be able to control plane, i.e. to set elevator, elevator in some > position instead of pushing the buttons. > > > I've heard that it is possible to control FlightGear via some "net_fdm > binary data exchange protocol", and that it is even included in MATLAB > for visualizing FlightGear. But didn't found any examples dedicated to > this protocol. > > > Could you please advice? Any solution that can give me 1) and 2) would > be great. > > > Good luck to all pilots, > > Artem Chernodub > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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 > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: Vadym K. <va...@gm...> - 2009-02-27 23:04:26
|
2009/2/27 Artem Chernodub <art...@ar...>: > Hello to everyone! > > I'm Ph.D. student from Kiev, Ukraine and I'm studying ways and methods > Заходи к нам на форум http://www.flightgear.ru/forum/ Там сейчас делают несколько самолей, есть знающие люди и всё по-русски могут обьяснить Хотя от помощи здесь тоже не отказывайся, конечно -- --- WBR, Vadym. |
From: Nicolas Q. <nqu...@gm...> - 2009-03-04 22:52:27
|
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. |
From: Detlef F. <fa...@so...> - 2009-03-05 07:00:01
|
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 Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel Greetings -- Detlef Faber http://www.sol2500.net/flightgear |
From: Alexis B. - x. <ale...@gm...> - 2009-03-05 10:06:16
|
Detlef Faber wrote: > 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! I used Nasal to build several rather complex systems, like Fuel System, Stab Augmentation System, Autopilot Logic, Terrain Avoidance Radar, Radar Warning Receiver and much more, and yes, I love Nasal too. If I have a problem, Melchior is (quite) almost there to help and provide solutions when new Nasal tools are needed. Having Andy close to the community is also great. Learning Nasal use was easy and fun and I din't found any limitation yet. I still don't understand why Nicolas does not like it. Alexis |
From: gerard r. <gh...@gm...> - 2009-03-05 12:23:13
|
On jeudi 05 mars 2009, Detlef Faber wrote: > 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. > > 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. However, with JSBSim, Nasal or any other script Langage could be mostly avoided. No problem to get an automatic flap, or to get an automatic taxying. Any JSBsim FDM model makers knows it. That Script Langage is becoming necessary when we want to use with some generic features ( instruments, radars ........) which are developed and offered with the base package. > 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. > > Greetings -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire |
From: Martin S. <Mar...@mg...> - 2009-03-05 10:49:18
|
Alexis Bory - xiii wrote: > Learning Nasal use was easy and fun and I din't found any limitation > yet. I still don't understand why Nicolas does not like it. I don't read from Nicolas' posting as that he "does not like" Nasal. Instead, he just explains in much detail why he considers his favourite alternative as being the better choice for the given task. And why he considers Nasal as being the re-implementation of an existing wheel. Certainly a lot of people have become pretty familiar with Nasal's features in FlightGear, but this alone doesn't automatically imply that it's the best _possible_ solution. At the time when Nasal was introduced into FlightGear it certainly had been the best solution _available_. But hey, if Andy Ross or someone else would have had provided the close integration of any different, cleverly designed scripting language XY into FlightGear, then everyone would now happily script in XY and nobody would care about Nasal. This is what the discussion is about - or at least was meant to be, if I understand Nicolas' impetus. Currently there is no choice, if you'd like to script in FlightGear, then you'll have to use Nasal. It remains to be seen how many people are going to jump onto another scripting language if they had the choice to experience the difference. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Melchior F. <mf...@ao...> - 2009-03-08 17:54:17
|
FlightGear needed a built-in scripting language, and it has one. A compact, clean, elegant and fast one. In total there are at the moment more than 170.000 lines of Nasal in *.nas files and a few thousands embedded in joystick drivers, dialog description files, model animation files, keyboard.xml, mice.xml and several other files. Extension functions interface perfectly to the property tree, the event manager, the built-in XML parser etc. Nasal is very tightly integrated in fgfs and used all over the place. The Lua language is quite similar to Nasal, even syntax-wise (where there are differences, Nasal is better IMHO). Do we want two similar languages embedded in fgfs side by side, so that people can choose? Hell, no! This is just needless bloat ("re-invention of the wheel" is an understatement!) and it would be a source of confusion. On which basis would people decide for one or the other? Would we expect them to evaluate both languages and to find out which works better for them? Or just take a random pick? What would be the advantage? That people who don't like Nasal can have something that's quite similar? Doesn't sound smart. So, having both in FlightGear is clearly not desirable. Would we want Lua to replace Nasal? Andy, the author of Nasal, is also FlightGear developer. He has done the integration in fgfs himself, he knows about our needs, he's almost daily in our IRC channel and always willing to answer questions or to improve the language. Lua just can't beat that. And it wouldn't be enough for Lua to be as good as Nasal, or slightly better. It would have to be vastly better to even be considered. It's an uphill battle and it doesn't look good for Lua. What are Lua's advantages? Random picks from Nicolas' email: "debugger": Sure, that's nice. We have several debugging utility functions for Nasal, but no debugger. But then again, I wouldn't often have needed one. And to quote a fellow fgfs developer after he had read the Lua wikipedia page: "No wonder they need a debugger!" (People might be thrilled to learn that Lua's arrays (which are emulated with hashes, because there are no arrays at all) start with index 1 (Shudder!). But that's not all: you *can* write to array[0] and don't get an error message, but Lua will silently throw the value away and return nil if you read it out! Yes, Lua badly needs a debugger! ;-) "documentation": True. Nasal could use some more. Nicolas could spend some of the time that integrating Lua would have taken for writing Nasal documentation. :-) These two points were the only clear advantages. What about the rest: "faster than nasal (that's an opinion, [...]": Exactly. Just an opinion, with no benchmarks to back it up. And even if it's slightly faster: the Nasal execution time is *not* a bottle-neck in fgfs by any means. "C API that allows loading of C/C++ modules through Lua": That's seriously presented as an advantage? It means that we would in no time see fgfs aircraft coming with binary blobs that users are supposed to install, but which they can't explore. That's not only dangerous, it also undermines FlightGear's Open Source character. This misfeature (in our context) alone should be enough to reject Lua! That's a gift for commercial freeloaders, not something that we profit from. If something needs to be fast, then we can code it in C++ right away, and make it available to all aircraft. "user community": Nasal and FlightGear have their own user communities, thanks. Nasal isn't FlightGear only. It's used in other projects as well. And the Lua community wouldn't buy us much either. We wouldn't want that aircraft depend on external Lua modules, which users would have to download from www.luarocks.org or wherever and install them just to fly that aircraft. People contribute to fgfs because they want to, not because they are already familiar with its scripting language, which is easy enough to learn. * Nicolas Quijano -- Wednesday 04 March 2009: > I really didn't want to get into that kind of argument (language > comparisons, etc) How telling! > In the game biz, it's never the best solution to roll your own [...] FlightGear is neither a game, nor a "biz". > 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 :) First: the property system was adopted *by* JSBSim. It's not something that JSBSim brought to the project. And second: Nasal has nothing to do with YASim other than it's by the same author. It doesn't have much to do with FDMs at all. It's used all over the place. Who was the source of this nonsense again? > it doesn't bother anyone that the overall feeling given by more > than a few longstanding community members is that Nasal is NOT well > liked, quite the contrary ? More from the uninformed source? Where's the evidence? Names please! Nobody ever said that s/he doesn't like Nasal to my knowledge. Many people said over time that they like it. I do. I can't stand the Lua verboseness ("end end end"). All of Nicolas' smearing seems based on false presumptions and questionable secret sources. Or are they just made up? Regarding my "veto" power (or lack thereof): It was clear that despite quotes and smiley this would make some people foam at their mouth. Of course, there's no formal veto power. But I am pretty sure that there will be no official FlightGear with Lua *and* me as an active contributor. Sure, the project could easily survive without me. Many people wouldn't even notice. (Just like it survived without Lua or Nicolas as a contributor. Has he even contributed a single line of code yet?) m. |
From: Erik H. <er...@eh...> - 2009-03-08 19:35:41
|
I've been silent in this thread mostly because I'm not very active as a developer these days, but it got me wondering why one would use lua instead of nasal. Searching for 'lua nasal' in google the first hit describes it all to my opinion: http://trainofthoughts.org/blog/2007/09/16/lua-popularity/ > If low footprint, then really low footprint, please… > > Or to stretch the point even further: if low footprint is really the ultimate reason for Lua (which is 13K LoC) and a reason against JavaScript (80K LoC) or even Perl (105K LoC), then I still do not understand why people not even use for instance Arena (14K LoC) or even NASAL (5K LoC). Arena and NASAL both at least are a lot more C/ C++ /Perl/ Java/ JavaScript style in their look and feel and so at least attract the “old-style” coders a lot more. I agree with this statement and therefore don't particularly like the idea to change scripting language just for the sake of it. I do wonder how well lua would handle the property system (and xml files) though. Erik |
From: Jon S. B. <jon...@co...> - 2009-03-08 21:38:33
|
Melchior is exactly right. JSBSim adopted the property system - which is a great piece of work by - was it David Megginson? I, too, have heard of some developers mixing Nasal scripts with all of the various FDMs, with great success. Jon From: Nicolas Quijano [mailto:nqu...@gm...] Sent: Sunday, March 08, 2009 4:00 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ? First: the property system was adopted *by* JSBSim. It's not something that JSBSim brought to the project. And second: Nasal has nothing to do with YASim other than it's by the same author. It doesn't have much to do with FDMs at all. It's used all over the place. Who was the source of this nonsense again? Archives & other tidbits written all over the vast world of FGFS (mis)information. Maybe you should get off your virtual throne and get down and dirty with documentation... Or is it so beneath you or uninteresting that it's better to keep on harping that the newcomers should do it ? Do you realize how totally crazy this sounds, especially in the context of Nasal (language, internals, APIs from two POVs : dev and user) ? You want people who don't know anything about it to document it ? |
From: Melchior F. <mf...@ao...> - 2009-03-08 22:32:08
|
* Jon S. Berndt -- Sunday 08 March 2009: > Melchior is exactly right. JSBSim adopted the property system - which is a > great piece of work by - was it David Megginson? Yes. For those who don't know him: David is/was also JSBSim developer, wrote SAX (Simple API for XML), and several of the core parts of fg/sg. And he also played a role in the famous Torvalds-Tanenbaum thread. :-) m. |
From: Melchior F. <mf...@ao...> - 2009-03-08 22:22:46
|
* Nicolas Quijano -- Sunday 08 March 2009: > As for "secret sources", they'll name themselves if they feel > like it, That would be fun! But I won't hold my breath. > No smearing at all, The nonsense about Nasal being bandaid for a "fledgling FDM" and nobody liking it, is just smearing Nasal and YASim based on undisclosed sources, not on reality. It's rare that I have to read so much nonsense here on the list. > Again, never my intent : we're talking about a fork, a specialized > version of FGFS. That's fine, then. * Melchior FRANZ -- Sunday 08 March 2009: > > What are Lua's advantages? Random picks from Nicolas' email: > > Arumph. Nothing random about your picking, at least be honest about it :) I meant "random" in the sense that when I assembled the list I only glanced over the message again, and tried to pick all relevant arguments, but was also aware that I'd probably miss some. That's where the randomness comes from. Just tell us what I forgot and I'll rip that apart as well. :-P > Quote from the horse's mouth, not someone's else reading of wikipedia !!! Huh? What makes you think I haven't immediately read the wikipedia article myself?! We discussed about it on IRC, but wikipedia is the source. > Nasal also needs the debugger and better sandboxing : making a parsing error > a fatal exception is not a long term solution... You can catch Nasal exceptions. > And no, I'm not surprised Melchior : you have time to play language police, > but no time to write docs, right ? [...] > Maybe you should get off your virtual throne and get down and dirty with > documentation... > Or is it so beneath you or uninteresting that it's better to keep on harping > that the newcomers should do it ? [...] > You'll send PMs about language constructs, and how people should code, but > you won't do the documentation work ? Another such fun-piece! Guess who wrote half of the existing documentation? http://wiki.flightgear.org/index.php/Nasal_scripting_language Check out the change history! You *really* don't know what you are talking about. As if you had to prove it ... > In my empirical experience, it's the number one cause of stuttering and > performance slowdowns (cue in wildfire) > I said experience, not evidence :) > Just because you say it's not a bottleneck, doesn't mean it's not. The wildfire author suspects that particles are the problem with wildfire slowness. > allowing current commercial exploitiers of FSX or earlier version of > the sim to bring their a/c to FGFS, something Curt himself expressed > interest in, Yes, but not by throwing our ideals away and open a can of worms. I would be surprised to learn that Curt wants to encourage commercial entities to enhance fgfs with closed, secret binary parts. Or with aircraft that come only with OSX and MS Windows binary blobs, but without Linux/Solaris/... blobs. Cross-platformness is an important goal of the FlightGear project, and has always been. > If the project's creator, and afaik, still manager/benign overlord to this > day, [...] but ultimately thanks to Curtis for starting it all a decade ago Somehow I think of David MURR when I read "project's creator", but Curt was AFAIK there at the very first hours (along with a few others). A co-founder, indeed. But this was long before my time, so I might be wrong here. > Oh, maybe because like my so-called "sources" you have your own reasons to > reply privately ? The reasons are: - self-proclaimed forum police trying to tell others what they can write - some forum admins asking for more censorship without acceptable reasoning - the dropping of ATOM/RSS with the last forum software update m. |