Re: [Flightgear-devel] Nasal'ing ...
[Sorry I've been so long getting back to this; I had to go to Japan on
short notice and this is the first chance I've had in the hotel room
to catch up on personal stuff without jet-lag. :)]
Boris Koenig wrote:
> I don't seem to be able to access a method like gui.Widget.new()
> from an object defined in another module, even though I _think_ ;-)
> I'm doing the right thing, basically that is:
>
> two ".nas"-files stored in /Nasal/ whose contents will be made
> available as modules within Nasal.
This is an ordering issue. Remember that "loading" and "running"
a script are the same thing in Nasal. If the test2 module loads
before test1, then test1 will not be initialized when test2 tries
to use it.
Some of the Nasal files get around this issue by doing their
initialization work in a timer that is registered to run after a
zero-length timeout. Look for a function called INIT() in several
scripts; I believe one of them has an extensive comment talking about
how the mechanism works.
What would be a better, permanent solution would be to support an
"import" feature. Thus, test2 could execute something like
import("test1") which would stop execution and load the test1 module
before returning. Note that this is another reason to support
recursive interpreter contexts, which I talked about earlier.
> But I did meanwhile play around with the mechanism that you used in
> that example, and I'm surprised to see that it _seems_ already quite
> possible to dynamically create a gui ... I haven't yet tried to
> create every PUI - control, but so far it's already extremely
> usable.
The current GUI system creates an interface out of a property tree.
That tree can be dynamically created with a Nasal script, so yes: what
you want to do is possible. Not every PUI binding is supported,
though. For example, you can create the interface dynamically, but
you can't change its structure at runtime (although you can destroy
and re-create the dialog, which might be good enough for many
purposes).
> > If those get used, you can end up in a situation where the "old"
> > and "new" versions of the file are in use simultaneously.
> > Likewise, think of timers registered by
> > the "old" version that get run after the new one is loaded.
>
> but, this shouldn't happen if the other Nasal code gets reloaded, too -
> right ?
No. Timers and other references are not stored symbolically. That
is, they are stored in C++ space as a NaRef object, which contains a
pointer into the garbage collected Nasal storage. The timer does not
store something like "module.SomeFunction()" which would do the symbol
lookup when executed. If you reload a module, references to the older
objects will stay alive.
> Also, what's the preferred way of implementing a basic "event loop"
> using Nasal, I've played around with this by using either a
> normal loop, or a timer - what's the best choice to poll a certain
> node from the property tree and act upon it assuming a certain
> value ?
You can't "spin" in a Nasal loop at the moment; you will just hang the
simulator. This would require the "multiple contexts" feature to
implement -- the Nasal subsystem could let a script execute for N
instructions and then put it on a "save" list for execution the next
frame.
Even then, there are significant performance and resource issues with
that kind of programming. Right now, polling in a timer is probably
your best bet.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal'ing ...
Andy Ross wrote: Boris Koenig wrote: 2)And: Is it possible to load a Nasal file while the game is running and execute it then ? Not currently. Adding it would actually be non-trivial, because (as in most similar languages) "loading" and "running" a script are the same thing. Being able to load a script from Nasal code is equivalent to running a recursive Nasal interpreter context, something that the current implemention doesn't support. So, if I really wanted to execute a script, I would really have to first nil'ing all existing nasal modules as well as the scripts from the property lists, in order to re-load then all of it INCLUDING the new file ? I suppose we could wire up an fgCommand that did a script load, which would work fine so long as you called it from a non-nasal context (keyboard binding, etc...). yes, actually I was not even (yet) thinking of loading one script from another one, rather I would like to have a way to load a particular script on demand, using a fgCommand linked to the menubar for that purpose would definitely be already sufficient. Fixing the interpreter to allow multiple contexts is definitely worth doing. This would also allow for a non-callback API, where a script could "sleep" for a bunch of frames and be woken up later on. This sounds at lot like the solution to a problem that I just mentioned: the event loop issue, so how are callbacks currently handled in Nasal ? -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal'ing ...
Sorry folks, this going to be a longer one ... Andy Ross wrote: Boris Koenig wrote: Thanks for the answers so far, I was already playing around with the gui.nas file, will have to look into it in more detail in order to see how to get the positioning part done, though. Essentially, you can just set x and y properties on the top level gui object. Yes, thanks for that - actually I meant _positioning_ part - I have now decided to simply use "\n"s for that purpose :-) Regarding the positioning, I did only have to additionally provide my own x/y values to a copy of the popupTip function - without really looking much into the widget object itself. There is a "Widget" helper class in there that can take some of the tedium out of handling the raw property interface. See the code for the fuel/weight dialog (gui.showWeightDialog()), which uses this API. yes, thanks - I was going to ask you about that weight dialog anyway: isn't that what you are doing there exactly what I wanted to do when I asked about "dynamically creating dialogs/dialog-elements using Nasal" - instead of using the hard-coded XML-files ? I'm not sure if you remember, but some time ago I posted a screenshot of FG showing a XML gui file with various dialogs and controls that I created manually, here: http://flitetutor.sourceforge.net/include.php?path=content/content.php&contentid=23 So, it seems like I can already create the dialogs itself - not sure about how well all of the controls are supported, though - (like, edit box, combo, buttons). But I did meanwhile play around with the mechanism that you used in that example, and I'm surprised to see that it _seems_ already quite possible to dynamically create a gui ... I haven't yet tried to create every PUI - control, but so far it's already extremely usable. Besides the fact, that combo boxes seem to be opened upwards by default - which is not feasible in some situations (e.g. look at the upper dialog on the screenshot) - so, an additional property like "upwards/downwards" might be useful - cause PUI itself allows such a specification already. Also, it seems to me that that the width property for combo boxes isn't being properly dealt with - even though I can (dynamically) create a PUI combo box control, the width value for that particular control does seem to be ignored - it's always displayed using a fixed width (no layouting applied !) - if you want me to send the corresponding code, just tell me. I will get back to the original replies within the next days, but a quick question: is there any way to make FlightGear re-initialize the Nasal loading routines ? Not currently. Adding it wouldn't be difficult, but the interaction issues can be very complicated. Existing Nasal code (loaded via the aircraft XML or other configuration) might be holding references to values in the the pre-existing modules. Okay, so then it would make more sense, to not only re-load the modules in /Nasal/ itself but rather also all the other stuff in order to circumvent potential problems ? So, basically I would also need to use void FGNasalSys::loadPropertyScripts() again, in order to load the Nasal scripts from the property files ? If those get used, you can end up in a situation where the "old" and "new" versions of the file are in use simultaneously. Likewise, think of timers registered by the "old" version that get run after the new one is loaded. but, this shouldn't happen if the other Nasal code gets reloaded, too - right ? But if you are careful about things and/or willing to troubleshoot this kind of issue, there's no reason it couldn't be done. I was actually not even looking for a really fool-proof way, rather it would already be perfectly sufficient not to have to re-start FG each time for every single modificiation to one of the Nasal-modules. So, I would not mind doing all the reloading again. Take a look at NasalSys::init() in src/Scripting/NasalSys.cxx. You'll want to extract the loop at the end (where it loads the files) and make it available as a fgCommand binding like "nasal-reload" or somesuch. Thank you ! That was as helpful as the source code itself :-) You'll want to delete the pre-existing modules first, of course (by doing something like "globals.gui = nil;", either in Nasal or using the extension API). As I'm not really familiar with all the internals, the safest way would probably be, to simply 'nil-ing' all the modules manually using Nasal, instead of actually deleting the hashes within FG, I think. Also, what's the preferred way of implementing a basic "event loop" using Nasal, I've played around with this by using either a normal loop, or a timer - what's the best choice to poll a certain node from the property tree and act upon it assuming a certain value ? Basically, I want to monitor several nodes at once and call a function (that then changes other properties) as soon as a certain condition is met. - Boris P.S.: To the doc-maintainer(s): How about adding all th
Re: [Flightgear-devel] Nasal'ing ...
Andy,
Thanks again for your last answer, it was indeed very precise and
helpful - but I'm not yet even getting back to the last reply,
rather I'm facing a new problem and wanted to ask you for your
feedback - I have got the following scenario:
I don't seem to be able to access a method like gui.Widget.new()
from an object defined in another module, even though I _think_ ;-)
I'm doing the right thing, basically that is:
two ".nas"-files stored in /Nasal/ whose contents will be made
available as modules within Nasal.
Now both of these contain objects, for example:
#test1.nas:
bla = {};
bla.method = func {
print "test1.bla.method() was called");
}
Now the other file:
#test2.nas
foo = {};
foo.method = func {
#Now I want to call test1.bla.method()
test1.bla.method();
};
The call to test1.bla.method(); does not seem to work
though, hence I thought this might something like a
namespace issue in C++ - do I have to use a special
notation in this nested example in order to actually
call the required function ?
Maybe, it's something terribly obvious ...
Thanks !
(wow, one of my shortest messages !)
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal'ing ...
Boris Koenig wrote: > Thanks for the answers so far, I was already playing around with the > gui.nas file, will have to look into it in more detail in order to > see how to get the positioning part done, though. Essentially, you can just set x and y properties on the top level gui object. There is a "Widget" helper class in there that can take some of the tedium out of handling the raw property interface. See the code for the fuel/weight dialog (gui.showWeightDialog()), which uses this API. > I will get back to the original replies within the next days, but a > quick question: is there any way to make FlightGear re-initialize the > Nasal loading routines ? Not currently. Adding it wouldn't be difficult, but the interaction issues can be very complicated. Existing Nasal code (loaded via the aircraft XML or other configuration) might be holding references to values in the the pre-existing modules. If those get used, you can end up in a situation where the "old" and "new" versions of the file are in use simultaneously. Likewise, think of timers registered by the "old" version that get run after the new one is loaded. But if you are careful about things and/or willing to troubleshoot this kind of issue, there's no reason it couldn't be done. Take a look at NasalSys::init() in src/Scripting/NasalSys.cxx. You'll want to extract the loop at the end (where it loads the files) and make it available as a fgCommand binding like "nasal-reload" or somesuch. You'll want to delete the pre-existing modules first, of course (by doing something like "globals.gui = nil;", either in Nasal or using the extension API). Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal'ing ...
Hi ! Thanks for the answers so far, I was already playing around with the gui.nas file, will have to look into it in more detail in order to see how to get the positioning part done, though. I will get back to the original replies within the next days, but a quick question: is there any way to make FlightGear re-initialize the Nasal loading routines ? I'm referring to those files within the Nasal subfolder that are automatically being made available as modules, I have tried all items within the debug submenu - unfortunately, none of these would also make FlightGear re-load the files in the Nasal folder, hence I still have to re-start FG for each change that I make to files that are in that folder, which is pretty inconvenient. Is there any undocumented fgCommand that I could use to have FG re-initialize the Nasal interpreter ? If not, it would probably fit quite well into the "debug" menu :-) What do you guys think ? While at it, Andy: I've read on your webpages that you can directly pass Nasal code to the interpreter and execute it then using the parseAndRun() method. Where exactly (in the FG source) is the object instantiated for the interpreter ? I'm asking this because I would like to add some simple way of "Nasal-console" to FlightGear, not even necessarily within the GUI-part (even though that would also be very neat), but rather I would simply open another console in order to pass nasal commands at runtime. Having a simple interactive console would certainly also be useful for other purposes. I think this would particularly simplify the development process, at least for the testing/debugging part of nasal code ... (Maybe, one could even export a new node within the property tree named "current-nasal-cmd" in order to be able to pass commands via telnet - another node "nasal-status" could keep the result of an operation (error code, string ...).) Thanks - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal'ing ...
Boris Koenig wrote: > 1)I would like to be able to display a simple text string at > runtime in the upper left corner of the screen using > Nasal (in order to display simple in-flight information). Check out gui.popupTip() to see if that does what you want. If not, you can look at the implementation (it is 100% Nasal code, and just uses the GUI module) to do something similar. > 2)And: Is it possible to load a Nasal file while the game is > running and execute it then ? Not currently. Adding it would actually be non-trivial, because (as in most similar languages) "loading" and "running" a script are the same thing. Being able to load a script from Nasal code is equivalent to running a recursive Nasal interpreter context, something that the current implemention doesn't support. I suppose we could wire up an fgCommand that did a script load, which would work fine so long as you called it from a non-nasal context (keyboard binding, etc...). Fixing the interpreter to allow multiple contexts is definitely worth doing. This would also allow for a non-callback API, where a script could "sleep" for a bunch of frames and be woken up later on. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Nasal'ing ...
Another possible issue with displaying ATC messages as dialogues is that, as far as I am aware, input bindings don't change; a mouse-controlled sim must pause and the esc key brings up the exit FGFS dialogue, rather than cancelling out of the current window. For the uninitiated, this can be extremely odd; the escape key is used in an attempt to cancel the dialogue, which brings up another dialogue. Because it's a reflexive key to remove unwanted dialogues, repeat until 5 exit FlightGear dialogues have displayed; by the time you've cleared them all your plane is probably either confusing ATC or confusing Search and Rescue. Giles Robertson -Original Message- From: David Luff [mailto:[EMAIL PROTECTED] Sent: 13 September 2004 13:50 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Nasal'ing ... On 9/13/04 at 10:16 AM Boris Koenig wrote: >Hi ! > >Two things: > >1) I would like to be able to display a simple text string at > runtime in the upper left corner of the screen using > Nasal (in order to display simple in-flight information). > > I could imagine that something like this already exists, i.e. > for displaying ATIS or traffic information during flight, is > there a specific node within the property tree available to > set such a "message" item dynamically so that's then displayed > automatically ? > No, the ATIS and ATC messages are displayed by FGATCDisplay, in src/ATC/ATCdisplay.[ch]xx. This is fairly cludgy code, liable to change on my whim (since currently no-one else uses it), and more importantly, only available if ATC is enabled. It is run by calling 'conventional' class functions, not by setting property tree values. > That way one could easily use Nasal to display runtime info, > one could also use such a feature to indicate things like that > the game's been paused (which is currently not being displayed) Norman did use exactly this (the atc display) to display a 'sim is paused' message once IIRC, but that got removed I think. I guess if you wanted something to get you going for now you could easily write a command binding to the ATC display and hence use it with Nasal, but I wouldn't rely on it in the long term. I was considering displaying ATC messages in pui dialogs, but am not sure if they can be kept on-top persistantly without blocking user input to the rest of FlightGear. The current code can be very hard to read depending on the colour of the background, although I suppose an arbitrary background colour could be drawn behind the text. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal'ing ...
On 9/13/04 at 10:16 AM Boris Koenig wrote: >Hi ! > >Two things: > >1) I would like to be able to display a simple text string at > runtime in the upper left corner of the screen using > Nasal (in order to display simple in-flight information). > > I could imagine that something like this already exists, i.e. > for displaying ATIS or traffic information during flight, is > there a specific node within the property tree available to > set such a "message" item dynamically so that's then displayed > automatically ? > No, the ATIS and ATC messages are displayed by FGATCDisplay, in src/ATC/ATCdisplay.[ch]xx. This is fairly cludgy code, liable to change on my whim (since currently no-one else uses it), and more importantly, only available if ATC is enabled. It is run by calling 'conventional' class functions, not by setting property tree values. > That way one could easily use Nasal to display runtime info, > one could also use such a feature to indicate things like that > the game's been paused (which is currently not being displayed) Norman did use exactly this (the atc display) to display a 'sim is paused' message once IIRC, but that got removed I think. I guess if you wanted something to get you going for now you could easily write a command binding to the ATC display and hence use it with Nasal, but I wouldn't rely on it in the long term. I was considering displaying ATC messages in pui dialogs, but am not sure if they can be kept on-top persistantly without blocking user input to the rest of FlightGear. The current code can be very hard to read depending on the colour of the background, although I suppose an arbitrary background colour could be drawn behind the text. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal'ing ...
Boris Koenig wrote: Hi ! Two things: 1)I would like to be able to display a simple text string at runtime in the upper left corner of the screen using Nasal (in order to display simple in-flight information). I could imagine that something like this already exists, i.e. for displaying ATIS or traffic information during flight, is there a specific node within the property tree available to set such a "message" item dynamically so that's then displayed automatically ? I don't think it exists at the moment. That way one could easily use Nasal to display runtime info, one could also use such a feature to indicate things like that the game's been paused (which is currently not being displayed) And I hardly dare to ask: if such an item doesn't yet exist, would anybody mind such an addition ? Nope. Sounds fine to me. 2)And: Is it possible to load a Nasal file while the game is running and execute it then ? I don't think there's any documented way to do it-a corresponding menu item certainly doesn't yet exist ;-) - at least I haven't seen anything like that, basically I would like certain scripts to be available/executed on demand, and not automatically be loaded/executed each time at startup (Nasal subfolder), that way it would be also easier to have multiple configurations running. In theory it should not be too hard to add this, but I don't think it is available already. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Nasal'ing ...
Hi ! Two things: 1) I would like to be able to display a simple text string at runtime in the upper left corner of the screen using Nasal (in order to display simple in-flight information). I could imagine that something like this already exists, i.e. for displaying ATIS or traffic information during flight, is there a specific node within the property tree available to set such a "message" item dynamically so that's then displayed automatically ? That way one could easily use Nasal to display runtime info, one could also use such a feature to indicate things like that the game's been paused (which is currently not being displayed) And I hardly dare to ask: if such an item doesn't yet exist, would anybody mind such an addition ? 2) And: Is it possible to load a Nasal file while the game is running and execute it then ? I don't think there's any documented way to do it-a corresponding menu item certainly doesn't yet exist ;-) - at least I haven't seen anything like that, basically I would like certain scripts to be available/executed on demand, and not automatically be loaded/executed each time at startup (Nasal subfolder), that way it would be also easier to have multiple configurations running. Thanks -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
