Richard Bytheway wrote:
Running make should only rebuild the parts of the source that have changed, and any parts of the source that are dependent on parts that have changed. You will always have to do the final link (20-30 seconds), but it shouldn't hit too much else.
Ya, thanks for that - I know, but it's still 350 megs stuff that I need
to keep on the drive, just for some minor changes ;-)
Sorry, if I wasn't clear about that.
Erik Hofman wrote:
Boris Koenig wrote:
How about adding a sub-directory lib to FlightGear/data/Nasal which
could then keep plugins that implement external Nasal functions ?
What do you think ?
I don't particulalry like the idea. I'de much rather concentrate on
imporving a FlightSimulator than on extening a scripting language.
I agree -that was actually the very reason why I suggested something
like that: *I* would take care of the plugin thing, so that *I* could
easily add new Nasal stuff - and so I wouldn't have to bother you guys
too much with my requirements anymore ;-)
That way the number of bindings to Nasal are as low as possible which
nakes
it easier to use.
I agree again, but there are some things that I would need to be added
to Nasal in order to really be able to use Nasal INSTEAD of doing things
_primarily_ in C++.
And meanwhile, I've really come to the conclusion that I like the
scripting approach - IF it allows for some more flexibility (see
my previous postings)
I realize there might be a difference between people who want a
scripting language to do everything they need and people who don't want
a scripting language except for some very specific tasks.
Well, don't get me wrong - _I_ don't want Nasal to do everything, it's
just that YOU suggested using Nasal instead of C++.
I don't want to make Nasal a fully bloated programming language,
but from what I can tell so far, there are about 6-10 additional
commands that I might need in order to really be able to absolutely
drop the C++ approach and concentrate on Nasal.
So, my motivation is NOT to make Nasal bloatware, just to add things
like support for :
- dynamic population of statically defined panels/dialogs
- simple file I/O (could be easily handleld by FlightGear
itself
- More advanced hooking techniques in order to allow for
some simple dragging and dropping of instruments/dialogs
within the authoring component of my FliteTutor concept.
Regarding the latter, imagine a simple dynamic panel dialog editor
that would be written using Nasal - this could even be integrated into
FlightGear itself, users would be able to create panels dialogs by
doing some dragging and droppinig of pre-defined FlightGear objects and
this stuff would then be saved in a standard XML file using PropertyList
syntax.
I am leaning towards the later (for FligthGear at least).
Yes, I can see - and this really wasn't meant to suggest Nasal should
become a Visual Basic pendant within FlightGear - rather just for
simpler adding of new functions/fgcommands.
--
Boris
P.S.: I've added a screenshot section to the webpage
(http://flitetutor.sourceforge.net) to show what I've
done so far (STATICALLY, using XML files) and what
I'd like to be able to do on the fly with Nasal.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
