Thread: [Celestia-developers] More scripting changes
Real-time 3D visualization of space
Status: Beta
Brought to you by:
cjlaurel
From: Chris L. <cl...@ww...> - 2003-04-13 05:42:04
|
I managed to implement the wait command in my Lua experiments. I ended up using coroutines to do it . . . My first attempt at it was a complete failure. But after revisiting the docs and rewriting my code, I think that I have a very clean and satisfactory implementation of control exchange between scripts and the Celestia event loop. I've checked in my changes. The affected files are celestiacore.* and celx.*. As before, the changes in celestiacore.cpp are #ifdef'd out, so nothing should be broken (and I checked on both Windows and Linux.) Here's another test script that I got working: -- Countdown from 10 i = 10 while (i > 0) do celestia:flash("Countdown: " .. i) i = i - 1 wait(0.25) end The next thing I'm going to do is implement the preload texture command. I expect that even if I just write it in the obvious way, it won't suffer any of the timing trickiness that the existing preload command does. I made one small change for the 1.3.0 release--it just cleans up the display of time rate by removing the extra .000. The build problems are concerning . . . will it be possible to get something that works on Mandrake, RedHat, and SuSE? This stuff is such a headache, and I'm at a loss as to what to do. --Chris |
From: Christophe T. <ch...@te...> - 2003-04-13 09:42:41
|
On Sunday 13 April 2003 08:31, Chris Laurel wrote: > The build problems are concerning . . . will it be possible to get > something that works on Mandrake, RedHat, and SuSE? This stuff is such a > headache, and I'm at a loss as to what to do. Yes, it's a headache. The problem is that we have to integrate two unrelated build systems: Gnome's and KDE's and to support three GUIs so I'm not surprised that there are problems, it's not really a standard setup. I'm confident we'll get it to work, eventually. -- Christophe |
From: Fridger S. <t0...@ma...> - 2003-04-13 15:50:56
Attachments:
Makefile.am.gz
log.gz
|
Christophe: I looked the automake docs up and spent quite some time over your Makefile.am code. The main problem is that the conditionals allowed are /very/ restrictive, at least in the 1.5 version of automake. I attach a modified Makefile.am.gz that works for me, but with your patch I still get an error upon compilation (cf. attached log.gz). Perhaps you have an idea of how to proceed further from here. Bye Fridger |
From: Christophe T. <ch...@te...> - 2003-04-13 16:00:38
|
On Sunday 13 April 2003 17:48, Fridger Schrempp wrote: > I attach a modified Makefile.am.gz that works for me, but with your patch I > still get an error upon compilation (cf. attached log.gz). Perhaps you have > an idea of how to proceed further from here. I've had this problem before, it comes from the KDE --enable-final option (normaly disabled by default) which ends up enabled (all cpp files are concatenated in one all_cpp.cpp file). On my system this happened only for gtk and glut build and having in configure.in AC_CHECK_COMPILERS for all builds fixed it for me. What options did you use in configure? -- Christophe |
From: Fridger S. <t0...@ma...> - 2003-04-13 16:19:53
|
Christophe Teyssier wrote: > > On Sunday 13 April 2003 17:48, Fridger Schrempp wrote: > > I attach a modified Makefile.am.gz that works for me, but with your patch I > > still get an error upon compilation (cf. attached log.gz). Perhaps you have > > an idea of how to proceed further from here. > > I've had this problem before, it comes from the KDE --enable-final option > (normaly disabled by default) which ends up enabled (all cpp files are > concatenated in one all_cpp.cpp file). > > On my system this happened only for gtk and glut build and having in > configure.in AC_CHECK_COMPILERS for all builds fixed it for me. > > What options did you use in configure? > > -- > Christophe ./configure --prefix=/opt/kde3 --with-kde --enable-final --disable-debug and for gtk, I use ./configure --prefix=/usr --with-gtk --enable-final --disable-debug Bye Fridger |
From: Christophe T. <ch...@te...> - 2003-04-13 16:21:46
|
On Sunday 13 April 2003 18:17, Fridger Schrempp wrote: > ./configure --prefix=/opt/kde3 --with-kde --enable-final --disable-debug > > and for gtk, I use > > ./configure --prefix=/usr --with-gtk --enable-final --disable-debug Then get rid of the --enable-final and it should work. --enable-final build size optimized apps (experimental - needs lots of memory) See? it's eXPerimental ;-) -- Christophe |
From: Fridger S. <t0...@ma...> - 2003-04-13 16:56:20
|
Christophe Teyssier wrote: > > On Sunday 13 April 2003 18:17, Fridger Schrempp wrote: > > ./configure --prefix=/opt/kde3 --with-kde --enable-final --disable-debug > > > > and for gtk, I use > > > > ./configure --prefix=/usr --with-gtk --enable-final --disable-debug > > Then get rid of the --enable-final and it should work. > > --enable-final build size optimized apps (experimental - needs lots > of memory) > > See? it's eXPerimental ;-) > > -- > Christophe +++ Allons enfants de la patrie...+++ Voila, encore un petit success de la collaboration franco-allemande;-) Ca marche, finalement! I went through all three settings --with-kde, --with-gtk and (for the first time) --with-glut. All three worked, but --with-glut produces the KDE GUI! Due to the simplistic conditionals, I get the following output after > make -f Makefile.cvs make -f Makefile.cvs This Makefile is only for the CVS repository This will be deleted before making the distribution *** Creating acinclude.m4 *** Creating aclocal.m4 *** Creating configure *** Creating config.h template autoheader: config.h.in is unchanged *** Creating Makefile templates *** Postprocessing Makefile templates found program with no _SOURCES: @ENABLE_GLUT_FALSE@@ENABLE_GTK_TRUE@am_celestia found program with no _SOURCES: @ENABLE_GLUT_TRUE@@ENABLE_GTK_TRUE@am_celestia *** Creating date/time stamp *** Finished Don't forget to run ./configure If you haven't done so in a while, run ./configure --help These combinations are not really interesting, are they? Bye Fridger |
From: Christophe T. <ch...@te...> - 2003-04-13 17:11:23
|
On Sunday 13 April 2003 18:54, Fridger Schrempp wrote: > +++ Allons enfants de la patrie...+++ > > Voila, encore un petit success de la collaboration franco-allemande;-) > > Ca marche, finalement! Es ist wunderbar ! > I went through all three settings --with-kde, --with-gtk and (for the first > time) --with-glut. All three worked, but --with-glut produces the KDE GUI! Yes, as I said in my first message you have to use --without-kde --without-gtk to get the GLUT interface. --with-gtk will also fall back to GLUT if the GTK libs or headers are not found. > Due to the simplistic conditionals, I get the following output after > > > make -f Makefile.cvs > > make -f Makefile.cvs > This Makefile is only for the CVS repository > This will be deleted before making the distribution > > *** Creating acinclude.m4 > *** Creating aclocal.m4 > *** Creating configure > *** Creating config.h template > autoheader: config.h.in is unchanged > *** Creating Makefile templates > *** Postprocessing Makefile templates > found program with no _SOURCES: > @ENABLE_GLUT_FALSE@@ENABLE_GTK_TRUE@am_celestia found program with no > _SOURCES: @ENABLE_GLUT_TRUE@@ENABLE_GTK_TRUE@am_celestia *** Creating > date/time stamp > *** Finished > Don't forget to run ./configure > If you haven't done so in a while, run ./configure --help > > These combinations are not really interesting, are they? No neither of them can happen. -- Christophe |
From: Chris L. <cl...@ww...> - 2003-04-14 06:57:49
|
On Sun, 13 Apr 2003, Christophe Teyssier wrote: > On Sunday 13 April 2003 18:54, Fridger Schrempp wrote: > > +++ Allons enfants de la patrie...+++ > > > > Voila, encore un petit success de la collaboration franco-allemande;-) > > > > Ca marche, finalement! > > Es ist wunderbar ! > Christophe and Fridger--great work on fixing the build scripts! Are you ready to package 1.3.0? I made one final change for 1.3.0 . . . Jack Higgins posted a very nice Pathfinder model, but loading it was making Celestia hang. I traced the problem to an apparent compiler bug in Microsoft Visual C++ 6. Adding an extra couple lines of code to the comparison function in 3dsmesh.cpp forces the compiler to generate different code that doesn't get stuck in an infinite loop when sorting. It's ugly, but it works, and the extra code should not impact performance in any noticeable way. It's also wrapped in an #if/#endif so Linux users don't have to suffer the a few extra bytes added to their executables. :) --Chris |
From: Christophe T. <ch...@te...> - 2003-04-14 08:12:44
|
Le Lundi 14 Avril 2003 09:47, Chris Laurel a =E9crit : > Christophe and Fridger--great work on fixing the build scripts! Are yo= u > ready to package 1.3.0? > > I made one final change for 1.3.0 . . . Jack Higgins posted a very nic= e > Pathfinder model, but loading it was making Celestia hang. I traced th= e > problem to an apparent compiler bug in Microsoft Visual C++ 6. Adding = an > extra couple lines of code to the comparison function in 3dsmesh.cpp > forces the compiler to generate different code that doesn't get stuck i= n > an infinite loop when sorting. It's ugly, but it works, and the extra = code > should not impact performance in any noticeable way. It's also wrapped= in > an #if/#endif so Linux users don't have to suffer the a few extra bytes > added to their executables. :) I'll commit the new build system tonight and we can then proceed with the= =20 release. -- Christophe |
From: Fridger S. <t0...@ma...> - 2003-04-14 08:26:28
|
Beyond 1.30: I was thinking, we could add a (temporary) command '--with-lua' in 'configure' along with an AC_CONDITIONAL <=> ENABLE_LUA in configure.in that would allow to set up in src/celestia/Makefile.am the additional routines to be compiled and lua libs to be linked, while we are experimenting with lua scripting. Costs little effort and makes things much more convenient for people to try the scripts out. Now that the final 5.0 version has appeared... Bye Fridger |
From: Chris L. <cl...@ww...> - 2003-04-14 08:34:46
|
On Mon, 14 Apr 2003, Fridger Schrempp wrote: > Beyond 1.30: > > I was thinking, we could add a (temporary) command '--with-lua' in 'configure' > along with an AC_CONDITIONAL <=> ENABLE_LUA in configure.in that would allow to > set up in src/celestia/Makefile.am the additional routines to be compiled and > lua libs to be linked, while we are experimenting with lua scripting. > > Costs little effort and makes things much more convenient for people to try the > scripts out. I agree completely, and I've been making an effort to keep all Lua-related code in Celestia inside #ifdef CELX blocks (btw, CELX = CELestia eXtension language) > Now that the final 5.0 version has appeared... It's very convenient that version 5.0 appeared . . . it's the first version with coroutines, which are crucial for embedding it in Celestia. --Chris |
From: Fridger S. <t0...@ma...> - 2003-04-14 08:45:04
|
Chris Laurel wrote: > > On Mon, 14 Apr 2003, Fridger Schrempp wrote: > > > Beyond 1.30: > > > > I was thinking, we could add a (temporary) command '--with-lua' in 'configure' > > along with an AC_CONDITIONAL <=> ENABLE_LUA in configure.in that would allow to > > set up in src/celestia/Makefile.am the additional routines to be compiled and > > lua libs to be linked, while we are experimenting with lua scripting. > > > > Costs little effort and makes things much more convenient for people to try the > > scripts out. > > I agree completely, and I've been making an effort to keep all Lua-related > code in Celestia inside #ifdef CELX blocks (btw, CELX = CELestia > eXtension language) > > > Now that the final 5.0 version has appeared... > > It's very convenient that version 5.0 appeared . . . it's the first > version with coroutines, which are crucial for embedding it in Celestia. > > --Chris It's getting late over there;-)...Here is a beautiful sunshine morning, spring is coming up fast at 53 deg N! I'll have a week off over Easter, starting this Wednesday, where I will get at last some time again for some celestia tasks waiting in the pipeline. Bye Fridger |
From: Christophe T. <ch...@te...> - 2003-04-14 19:38:24
|
On Monday 14 April 2003 11:24, Chris Laurel wrote: > On Mon, 14 Apr 2003, Fridger Schrempp wrote: > I agree completely, and I've been making an effort to keep all Lua-related > code in Celestia inside #ifdef CELX blocks (btw, CELX = CELestia > eXtension language) I've commited the new build system. I've also added options to enable CELX: --with-lua --with-lua-includes --with-lua-libs I've also had to change: #include "lua/lua.h" and #include "lua/lualib.h" to #include "lua.h" and #include "lualib.h" since on Linux Lua is installed in /usr/local by default. -- Christophe |
From: Fridger S. <t0...@ma...> - 2003-04-14 19:45:06
|
Christophe Teyssier wrote: > > On Monday 14 April 2003 11:24, Chris Laurel wrote: > > On Mon, 14 Apr 2003, Fridger Schrempp wrote: > > I agree completely, and I've been making an effort to keep all Lua-related > > code in Celestia inside #ifdef CELX blocks (btw, CELX = CELestia > > eXtension language) > > I've commited the new build system. > I've also added options to enable CELX: > --with-lua > --with-lua-includes > --with-lua-libs > > I've also had to change: > #include "lua/lua.h" and #include "lua/lualib.h" > to > #include "lua.h" and #include "lualib.h" > since on Linux Lua is installed in /usr/local by default. > > -- > Christophe Great. I have also finished the --with-lua options, but not yet committed, since I was waiting for you to check the other stuff in first;-). At least, I have learned meanwhile, how to do configure.in's and Makefile.am's... I'll check yours out right now. Bye Fridger |
From: Christophe T. <ch...@te...> - 2003-04-14 20:04:08
|
On Monday 14 April 2003 21:42, Fridger Schrempp wrote: > Great. I have also finished the --with-lua options, but not yet committed, > since I was waiting for you to check the other stuff in first;-). > > At least, I have learned meanwhile, how to do configure.in's and > Makefile.am's... > > I'll check yours out right now. I've just added support for the CelX scripts in kdeapp.cpp. *.cel files are handled as before and *.celx files use the Lua engine. I've just tested the exemple script: -- Countdown from 10 i = 10 while (i > 0) do celestia:flash("Countdown: " .. i) i = i - 1 wait(0.25) end It works well, but at the end of it I get the following error on the console: Error: cannot resume dead coroutine -- Christophe |
From: Chris L. <cl...@ww...> - 2003-04-14 20:30:54
|
On Mon, 14 Apr 2003, Christophe Teyssier wrote: > On Monday 14 April 2003 21:42, Fridger Schrempp wrote: > > Great. I have also finished the --with-lua options, but not yet committed, > > since I was waiting for you to check the other stuff in first;-). > > > > At least, I have learned meanwhile, how to do configure.in's and > > Makefile.am's... > > > > I'll check yours out right now. > > I've just added support for the CelX scripts in kdeapp.cpp. > > *.cel files are handled as before and *.celx files use the Lua engine. > > I've just tested the exemple script: > -- Countdown from 10 > i = 10 > while (i > 0) do > celestia:flash("Countdown: " .. i) > i = i - 1 > wait(0.25) > end > > It works well, but at the end of it I get the following error on the console: > Error: cannot resume dead coroutine That's expected . . . I keep calling resume on the script until there's an error. The 'cannot resume dead coroutine' error means that the script is finished. As far as I can tell, there's no way to tell whether the script is just finished or a real error occurred. I checked in some new scripting stuff last night . . . celestia:find, celestia:select, and celestia:goto are all working, albeit in a somewhat limited fashion. A sample usage is: obs = celestia:getobserver() o = celestia:find("Sol/Earth") obs:goto(o) The goto command will eventually allow optional parameters for things like the travel time. And of course, if you have a script that does a lot of gotos, you might want to right a function to simplify your code: function goto(x) local o = celestia:find(x) celestia:getobserver():goto(o) end Note that functions are first-class objects in Lua, so this: function goto(x) is just syntactic sugar for: goto = function(x) --Chris |
From: Fridger S. <t0...@ma...> - 2003-04-14 21:41:51
|
Chris Laurel wrote: > > I checked in some new scripting stuff last night . . . celestia:find, > celestia:select, and celestia:goto are all working, albeit in a somewhat > limited fashion. > > A sample usage is: > > obs = celestia:getobserver() > o = celestia:find("Sol/Earth") > obs:goto(o) > > The goto command will eventually allow optional parameters for things like > the travel time. > > And of course, if you have a script that does a lot of gotos, you might > want to right a function to simplify your code: > > function goto(x) > local o = celestia:find(x) > celestia:getobserver():goto(o) > end > > Note that functions are first-class objects in Lua, so this: > function goto(x) > is just syntactic sugar for: > goto = function(x) > > --Chris > This all works fine for me, too. Question: what about local vs global variables? Is everything defined within function(x) automatically local? Amusingly, it turns out that I speak "Lua" since a long time without being aware of it: The programming language used in the well-known algebraic manipulation package Maple that I am using daily in my research, is /largely/ identical, it seems. Bye Fridger |
From: Chris L. <cl...@ww...> - 2003-04-14 22:03:59
|
On Mon, 14 Apr 2003, Fridger Schrempp wrote: > Chris Laurel wrote: > > > > > I checked in some new scripting stuff last night . . . celestia:find, > > celestia:select, and celestia:goto are all working, albeit in a somewhat > > limited fashion. > > > > A sample usage is: > > > > obs = celestia:getobserver() > > o = celestia:find("Sol/Earth") > > obs:goto(o) > > > > The goto command will eventually allow optional parameters for things like > > the travel time. > > > > And of course, if you have a script that does a lot of gotos, you might > > want to right a function to simplify your code: > > > > function goto(x) > > local o = celestia:find(x) > > celestia:getobserver():goto(o) > > end > > > > Note that functions are first-class objects in Lua, so this: > > function goto(x) > > is just syntactic sugar for: > > goto = function(x) > > > > --Chris > > > > > This all works fine for me, too. > > Question: what about local vs global variables? Is everything defined within > function(x) automatically local? The default is global, which is one of the few nits in the language. I think that making local definition the default makes the most sense. You can specify local scope by adding local in front of the initial assignment; this is what I did in my goto function. > Amusingly, it turns out that I speak "Lua" since a long time without being > aware of it: The programming language used in the well-known algebraic > manipulation package Maple that I am using daily in my research, is /largely/ > identical, it seems. Interesting . . . I wonder if there's a connection? Maple has been around a lot longer than Lua. --Chris |
From: Fridger S. <t0...@ma...> - 2003-04-14 22:18:42
|
Chris Laurel wrote: > > > > > This all works fine for me, too. > > > > Question: what about local vs global variables? Is everything defined within > > function(x) automatically local? > > The default is global, which is one of the few nits in the language. I > think that making local definition the default makes the most sense. You > can specify local scope by adding local in front of the initial > assignment; this is what I did in my goto function. > > > Amusingly, it turns out that I speak "Lua" since a long time without being > > aware of it: The programming language used in the well-known algebraic > > manipulation package Maple that I am using daily in my research, is /largely/ > > identical, it seems. > > Interesting . . . I wonder if there's a connection? Maple has been around > a lot longer than Lua. > > --Chris I had found in your previous example already that the default is /exactly as in Maple/: 'global' if there is no 'local' statement within the function! The two languages are virtually /identical/, it seems. I have bought a site licence of Maple for my laboratory about 13 years ago! The language was created by a group of mathematicians (before Maple was commercialized) and has virtually not changed since. I know these guys by name. It should be easy to check for any connections to Brazil;-). Before I bought the licence, a colleague of mine and I thoroughly checked the Maple language architecture and its performance. I am really familiar with it;-). Incidentally, of course, the old 'wait' problem (missing 'handshake') still prevails: if you call goto("Sol/Earth") wait(...) goto("Sol/Saturn") then Earth is simply skipped, if the wait(...) is not fine-tuned... Bye Fridger |
From: Chris L. <cl...@ww...> - 2003-04-14 22:36:02
|
> Incidentally, of course, the old 'wait' problem (missing 'handshake') still > prevails: if you call > > goto("Sol/Earth") > wait(...) > goto("Sol/Saturn") > > then Earth is simply skipped, if the wait(...) is not fine-tuned... The wait should be as long as the goto time (5 seconds by default). This is by design, as a synchronous goto can be easily implemented in terms of an instantaneous one: function syncgoto(x) goto(x) wait(5) end But possibly the texture loads are causing problems? If so, I wonder if adding a wait(0) before the wait(5) might help, at least until I've implemented the preload() function. --Chris |
From: Fridger S. <t0...@ma...> - 2003-04-14 23:12:24
|
Chris Laurel wrote: > > > Incidentally, of course, the old 'wait' problem (missing 'handshake') still > > prevails: if you call > > > > goto("Sol/Earth") > > wait(...) > > goto("Sol/Saturn") > > > > then Earth is simply skipped, if the wait(...) is not fine-tuned... > > The wait should be as long as the goto time (5 seconds by default). This > is by design, as a synchronous goto can be easily implemented in terms of > an instantaneous one: > > function syncgoto(x) > goto(x) > wait(5) > end > > But possibly the texture loads are causing problems? If so, I wonder if > adding a wait(0) before the wait(5) might help, at least until I've > implemented the preload() function. > > --Chris But in my opinion this is really not ideal and also not very elegant, since there may be all sorts of delaying factors in different machine setups. Texture loads is just one thing, with more complex scripts, there may be many more severe issues without a 'handshake' mechanism. Imagine you search a database without knowing how long it takes and --depending on the result-- then want to go somewhere etc...Then besides a preload() you also need a presearch() etc;-). I have meanwhile read quite a bit in the Lua docu: Maple and Lua are /identical/, apart from just cosmetic differences. In addition --and this is curious-- the authors of Lua have formulated Lua in their PhD theses at the beginning of the 90's already ('90 and '92), much closer to the time when Maple took off;-). In particular, concepts like 'type'/type-checking and 'table = {"a","b","c",... }' are very typical and most important in Maple as well. The syntax is also almost identical. Bye Fridger |
From: Chris L. <cl...@ww...> - 2003-04-14 23:33:28
|
On Tue, 15 Apr 2003, Fridger Schrempp wrote: > Chris Laurel wrote: > > > > > Incidentally, of course, the old 'wait' problem (missing 'handshake') still > > > prevails: if you call > > > > > > goto("Sol/Earth") > > > wait(...) > > > goto("Sol/Saturn") > > > > > > then Earth is simply skipped, if the wait(...) is not fine-tuned... > > > > The wait should be as long as the goto time (5 seconds by default). This > > is by design, as a synchronous goto can be easily implemented in terms of > > an instantaneous one: > > > > function syncgoto(x) > > goto(x) > > wait(5) > > end > > > > But possibly the texture loads are causing problems? If so, I wonder if > > adding a wait(0) before the wait(5) might help, at least until I've > > implemented the preload() function. > > > > --Chris > > But in my opinion this is really not ideal and also not very elegant, since > there may be all sorts of delaying factors in different machine setups. Texture > loads is just one thing, with more complex scripts, there may be many more > severe issues without a 'handshake' mechanism. Imagine you search a database > without knowing how long it takes and --depending on the result-- then want to > go somewhere etc...Then besides a preload() you also need a presearch() etc;-). OK . . . So perhaps what's needed is function wait_until_stop. Or, extend wait to be able to accept an event argument, so you'd write something like wait(until("stopped")) In either case, the function would return control to Celestia until the observer mode was no longer 'Travelling' That should work better than specifying a time, and it also makes clearer the intent of the wait. --Chris |
From: Chris L. <cl...@ww...> - 2003-04-15 05:18:14
|
On Mon, 14 Apr 2003, Chris Laurel wrote: > On Tue, 15 Apr 2003, Fridger Schrempp wrote: > > > Chris Laurel wrote: > > > > > > > Incidentally, of course, the old 'wait' problem (missing 'handshake') still > > > > prevails: if you call > > > > > > > > goto("Sol/Earth") > > > > wait(...) > > > > goto("Sol/Saturn") > > > > > > > > then Earth is simply skipped, if the wait(...) is not fine-tuned... > > > > > > The wait should be as long as the goto time (5 seconds by default). This > > > is by design, as a synchronous goto can be easily implemented in terms of > > > an instantaneous one: > > > > > > function syncgoto(x) > > > goto(x) > > > wait(5) > > > end > > > > > > But possibly the texture loads are causing problems? If so, I wonder if > > > adding a wait(0) before the wait(5) might help, at least until I've > > > implemented the preload() function. > > > > > > --Chris > > > > But in my opinion this is really not ideal and also not very elegant, since > > there may be all sorts of delaying factors in different machine setups. Texture > > loads is just one thing, with more complex scripts, there may be many more > > severe issues without a 'handshake' mechanism. Imagine you search a database > > without knowing how long it takes and --depending on the result-- then want to > > go somewhere etc...Then besides a preload() you also need a presearch() etc;-). > > OK . . . So perhaps what's needed is function wait_until_stop. Or, > extend wait to be able to accept an event argument, so you'd write > something like wait(until("stopped")) > > In either case, the function would return control to Celestia until the > observer mode was no longer 'Travelling' That should work better than > specifying a time, and it also makes clearer the intent of the wait. I checked in some more Lua script improvements . . . First of all, I dramatically cleaned up the way methods for the 'classes' are exported to Lua. A single line will now suffice . . . for example: RegisterMethod(l, "goto", observer_goto); Feel free to experiment with adding your own script functionality. Second, I added a number of new methods for the observer class: follow, synchronous, lock, chase, track, and travelling. The travelling() method is only one that requires some explanation. It returns true if the observer is still moving as a result of a goto, center, or similar function. This should suffice as a 'handshake' mechanism, Fridger, though I would like eventually to develop something more elegant. Here's how you would wait for a goto to complete: obs = celestia:getobserver() while (obs:travelling()) do wait(0) end This code just polls the observer waiting for it to stop moving. My goto wrapper now looks like this: function goto(target, t) local o = celestia:find(target) local obs = celestia:getobserver() obs:goto(o, t) while (obs:travelling()) do wait(0) end end The body of my test script is just this: goto("Sol/Mars", 1) wait(1) goto("Sol/Pluto", 1) The script zips to Mars in one second, pauses there for a second, then zooms off to Pluto. The key thing is that Mars is visible for the /entire/ one second pause--no tricky time adjustment is required. Also, note that I've extended the goto command to accept the travel time as an optional second parameter. --Chris |
From: Fridger S. <t0...@ma...> - 2003-04-15 08:36:51
|
Chris Laurel wrote: > > On Mon, 14 Apr 2003, Chris Laurel wrote: > > > On Tue, 15 Apr 2003, Fridger Schrempp wrote: > > > > > Chris Laurel wrote: > > > > > > > > > Incidentally, of course, the old 'wait' problem (missing 'handshake') still > > > > > prevails: if you call > > > > > > > > > > goto("Sol/Earth") > > > > > wait(...) > > > > > goto("Sol/Saturn") > > > > > > > > > > then Earth is simply skipped, if the wait(...) is not fine-tuned... > > > > > > > > The wait should be as long as the goto time (5 seconds by default). This > > > > is by design, as a synchronous goto can be easily implemented in terms of > > > > an instantaneous one: > > > > > > > > function syncgoto(x) > > > > goto(x) > > > > wait(5) > > > > end > > > > > > > > But possibly the texture loads are causing problems? If so, I wonder if > > > > adding a wait(0) before the wait(5) might help, at least until I've > > > > implemented the preload() function. > > > > > > > > --Chris > > > > > > But in my opinion this is really not ideal and also not very elegant, since > > > there may be all sorts of delaying factors in different machine setups. Texture > > > loads is just one thing, with more complex scripts, there may be many more > > > severe issues without a 'handshake' mechanism. Imagine you search a database > > > without knowing how long it takes and --depending on the result-- then want to > > > go somewhere etc...Then besides a preload() you also need a presearch() etc;-). > > > > OK . . . So perhaps what's needed is function wait_until_stop. Or, > > extend wait to be able to accept an event argument, so you'd write > > something like wait(until("stopped")) > > > > In either case, the function would return control to Celestia until the > > observer mode was no longer 'Travelling' That should work better than > > specifying a time, and it also makes clearer the intent of the wait. > > I checked in some more Lua script improvements . . . > > First of all, I dramatically cleaned up the way methods for the 'classes' > are exported to Lua. A single line will now suffice . . . for example: > > RegisterMethod(l, "goto", observer_goto); > > Feel free to experiment with adding your own script functionality. > > Second, I added a number of new methods for the observer class: follow, > synchronous, lock, chase, track, and travelling. The travelling() method > is only one that requires some explanation. It returns true if the > observer is still moving as a result of a goto, center, or similar > function. This should suffice as a 'handshake' mechanism, Fridger, though > I would like eventually to develop something more elegant. > > Here's how you would wait for a goto to complete: > > obs = celestia:getobserver() > while (obs:travelling()) do > wait(0) > end > > This code just polls the observer waiting for it to stop moving. My goto > wrapper now looks like this: > > function goto(target, t) > local o = celestia:find(target) > local obs = celestia:getobserver() > obs:goto(o, t) > while (obs:travelling()) do > wait(0) > end > end > > The body of my test script is just this: > > goto("Sol/Mars", 1) > wait(1) > goto("Sol/Pluto", 1) > > The script zips to Mars in one second, pauses there for a second, then > zooms off to Pluto. The key thing is that Mars is visible for the > /entire/ one second pause--no tricky time adjustment is required. Also, > note that I've extended the goto command to accept the travel time as an > optional second parameter. > > --Chris Bingo! That's precisely as I had it in mind, >Suppose, I furnish every scripting command with a return flag, >say 0, that is only set after the command has been successfully >completed, then in usual shell scripting, I would just do > while (command) >.....remain in some loop... Such 'flow control' or 'handshake' mechanisms already worked much before the times of multi threading;-). What is also excellent is that the numerical time delay in the wait() statement is then the actual available 'pause' time. I am looking forward to trying the new commands out tonight, when I am home. Since I happen to be a 'Lua expert' because of my vast Maple know how;-), I am sure I will soon find plenty of new and useful functionalities for the new scripting. Bye Fridger |