Celestia Forums

Hi everyone. I need your help. I am trying to write a short script to go to this position in a celx script, within Vincent's Lua Edu tools feature. Celx scripts do not currently recognize cel:URL's, without calling a special function. When I use that function inside Lua Edu Tools, it does not work because the Lua Edu Tools feature uses its own internal scripts. Its complicated.

Anyway, here is the place I want to go:

cel://Follow/Milky%20Way/2010-01-12T01:00:51.92234?x=AAAAAAAAEA+YkcBQWP///w&y=AAAAAAAAN+aA47qVEQ&z=AAAAAAAAwk0ZLPk5x////w&ow=-0.385606&ox=-0.677335&oy=-0.378058&oz=0.499597&select=Milky%20Way&fov=32&ts=1&ltd=0&p=0&rf=513943&lm=128&tsrc=0&ver=3

I need the exact celx script "gotoposition" commands that I can add to a celx script, to go to that spot. Can anyone please help me?

Thanks in advance

Frank

fsgregs wrote:Hi everyone. I need your help. I am trying to write a short script to go to this position in a celx script, within Vincent's Lua Edu tools feature. Celx scripts do not currently recognize cel:URL's, without calling a special function. When I use that function inside Lua Edu Tools, it does not work because the Lua Edu Tools feature uses its own internal scripts. Its complicated.

Frank,
Are you saying that the setURL command doesn't work inside the Lua Tools? This would work in any normal celX script.
(I haven't downloaded Vincent's tools yet, so I can't confirm this problem, but I gather that is what you are saying.)

CC

Are you saying that the setURL command doesn't work inside the Lua Tools? This would work in any normal celX script.

My problem occurs because I am trying to call a celx script, from within another script, a lua script. One lua script cannot be called from within another one, according to Vincent. Here is what he said about the problem:

Actually, the problem doesn't come from the Lua Tools, but from the
fact that your script is launched from within another script -- a Lua
script. You'd have the same problem if you tried to call your script
from another celx script. The problem comes from the loadfile() or
dofile() functions thar are used to run the second script. Using these
functions, Celestia doesn't recognize the second script as a Celestia
script, and some special functions like CEL(source) or even the wait()
command are simply ignored, which can be quite anoying.

I'm about to add a celestia:runscript command to Celestia 1.6.1 that
will fix this issue. With this command, the second script, whatever
its content, will run correctly.

Its a bit complicated, but simply put, I need to use a gotoposition command to travel to the spot that my celURL would take me to if I clicked on it separately. If you click on that celURL and go to that spot, what would I type in a celx script to go to that same time and place without the use of a celURL? I have no idea how to find my position and I am a total illiterate in celx scripting. If anyone can help me, I'd most appreciate it.

Thanks

Frank

--- edit ---

John,
Nice to see you thinking outside the box, but unfortunately, even if that was to work, it's OS specific. We need a solution that works across Windows, Mac, and Linux platforms.

Frank,
I think that rather than call one celx file from another, what we need really is to be able to place several scripts in the same folder and have access to any of their methods from any other script in the same folder. ie. Execute the function, rather than the file.
(Essentially a library of functions, if you get my drift).

I don't know enough about LUA/celX at present to know whether this is possible, but maybe Vincent knows.
Would this also solve your problem?

Chuft-Captain wrote:John,
Nice to see you thinking outside the box, but unfortunately, even if that was to work, it's OS specific. We need a solution that works across Windows, Mac, and Linux platforms.
...

CC,

that's NOT at all an OS specific proposal. The 'bash' and other clever shells from UNIX are all available under Windows, of course. I would never even touch Windows, without these shells. This would mean spending my time with CLICKING ...my God what a horror!

I am not joking here:
For most IT experts who are usually VERY fast with the keyboard, every click means interrupting your typing, grabbing the mouse and then returning to some standard "10 finger typing" position. This takes a LOT of unnecessary time and concentration...

Fridger

--- edit ---

t00fri wrote:that's NOT at all an OS specific proposal. The 'bash' and other clever shells from UNIX are all available under Windows, of course. I would never even touch Windows, without these shells

Perhaps I need to rephrase the statement... "We need a solution that works across standard Windows, Mac, and Linux platforms, without the installation of additional environments."

Of course Unix environments are available under Windows, but my point was that any given CELX script written in one environment should (at least IMO) be able to run correctly in the other OS's without the pre-requisite installation of additional environments like Cygwin. (Otherwise we're just adding complexity and creating an additional requirement/dependency for running CELX scripts in those other environments.)
ie. Ideally the solution needs to be based in LUA or C++ (both platform independent from a software development perspective), rather than being dependent on the presence of any additional shell or other tool in a given user's configuration.
If a Celestia user doesn't have these shells installed, or the where-with-all to install them, they still should be able to run the scripts.

Chuft-Captain wrote:

t00fri wrote:that's NOT at all an OS specific proposal. The 'bash' and other clever shells from UNIX are all available under Windows, of course. I would never even touch Windows, without these shells

Perhaps I need to rephrase the statement... "We need a solution that works across standard Windows, Mac, and Linux platforms, without the installation of additional environments."

Of course Unix environments are available under Windows, but my point was that any given CELX script written in one environment should (at least IMO) be able to run correctly in the other OS's without the pre-requisite installation of additional environments like Cygwin. (Otherwise we're just adding complexity and creating an additional requirement/dependency for running CELX scripts in those other environments.)
ie. Ideally the solution needs to be based in LUA or C++ (both platform independent from a software development perspective), rather than being dependent on the presence of any additional shell or other tool in a given user's configuration.
If a Celestia user doesn't have these shells installed, or the where-with-all to install them, they still should be able to run the scripts.

CC,

these shells are standard both in MAC OS and Linux. No further installation necessary. The bash comes with the OS. So what is left is Windows. It all depends on what people want to do. E.g. if you don't install VS 2008 Express in addition, you won't be able to build Celestia under Windows. That's too bad, isn't it since meanwhile Celestia-compilation is done with a single CLICK after downloading the sources. For me a compiler is a standard configuration in ANY OS, notably a (free) compiler by Microsoft in Windows...

So what's the difference that one would be unable to run those scripts without clicking ONCE more: namely to install the stand-alone win-bash.

http://win-bash.sourceforge.net/

The win-bash needs no special environment or DLLs. There is just one binary and that's it.

You will presumably reply that some of the Noops will be unable to install the win-bash with a CLICK (after having installed Celestia with a previous CLICK ) ...

Fridger

t00fri wrote:CC,

these shells are standard both in MAC OS and Linux. No further installation necessary. The bash comes with the OS. So what is left is Windows. It all depends on what people want to do. E.g. if you don't install VS 2008 Express in addition, you won't be able to build Celestia under Windows. That's too bad, isn't it since meanwhile Celestia-compilation is done with a single CLICK after downloading the sources. For me a compiler is a standard configuration in ANY OS, notably a (free) compiler by Microsoft in Windows...

So what's the difference that one would be unable to run those scripts without clicking ONCE more: namely to install the stand-alone win-bash.

http://win-bash.sourceforge.net/

The win-bash needs no special environment or DLLs. There is just one binary and that's it.

You will presumably reply that some of the Noops will be unable to install the win-bash with a CLICK (after having installed Celestia with a previous CLICK ) ...

Fridger

Ha,
Your mind-reading always amuses me.

Ok, I'll bite! ...
I would say that MOST of the Celestia Users in the world would probably expect to install the Celestia executable and then have everything just work out of the box.
Unlike you, I don't think that's an unreasonable expectation (regardless of their CLICK proficiency. :LOL:).
I don't know how many (Windows) Celestia Users there are in total worldwide, maybe 100,000, 1,000,000?? ... Chris may have some idea from download stats, but I'm sure that the vast majority wouldn't know (or want) to check either here or at CM in order to keep up to date with the latest DLL they need to install into their OS in order to run scripts.

So, to cater for these users (the majority), if win-bash was to be a pre-requisite to running certain types of scripts, then really it should be packaged (if it's license permits) with the (Windows) Celestia Installation.

I'm not however advocating that, as I still contend that the more elegant solution is to find a way to achieve what we want within LUA... which would make the whole bash argument moot.
That's in an ideal world of course, but anyway that's my 4CW.

I suspect the elegant solution probably won't be possible as LUA's a scripting language rather than a compiled language, and may have some limitations wrt. cross-file exposure of methods/functions.

CC

PS. Chris, if you're following this, I'd be interested to know what is your estimate of Celestia Users worldwide?? MAC/LINUX/WIN
(Number of downloads with each major release might give an idea.)

CC,

it is quite obvious that the best solution would be staying within lua.

But sorry, I see our little discussion more generally. So many Windows users don't even KNOW they are having cmd.exe, the Windows console that accepts commands. Same for MAC OS users: many don't even KNOW that they are having a complete UNIX OS underneath with a most clever 'bash' etc.

win-bash or bash via CYGWIN is such a versatile console tool that cmd.exe just looks like a prehistoric something. Quite seriously once more: I would not mess around with Windows without having one of these UNIX shells as a fast and most powerful interface for my daily work.

Fridger

PS: The Celestia download statistic is easily inspected at SourceForge. The total download numbers range around 7 million meanwhile. Windows is certainly the dominant fraction. But this doesn't mean that all Windows users share the same attitudes ...

t00fri wrote:But sorry, I see our little discussion more generally...

... whereas I've been trying hard to remain on the subject of how best to get CELX scripts calling each others methods, which may in fact solve Franks problem. (regardless of the usual arguments about the merits of the different platforms)....Of course, it's quite possible that there is no way to do this keeping within LUA.
... Apology accepted!

t00fri wrote:PS: The Celestia download statistic is easily inspected at SourceForge. The total download numbers range around 7 million meanwhile. Windows is certainly the dominant fraction. But this doesn't mean that all Windows users share the same attitudes ...

Thanks for that. -- I didn't know those stats were there.
If you're interested, see here: Celestia D/L stats from Sourceforge presented graphically

CC

Here are the different options we currently have to launch a second celx script from within a Lua or celx script:

1- Use the Lua dofile() or loadfile() commands.
However, these functions will run the content of the second script as a Lua chunk that won't be
recognized by celestiacore as a celestia script. And thus, special commands like wait() or celscript:tick()
will be simply ignored. This can be quite annoying since the wait() command is pretty frequently used.
A workaround would be to run the second script in a different thread, and use coroutines to yield and
resume the script. But this is really complex and I've never managed to make it work correctly...

2- Use the Lua os.execute() function to execute an operating system shell command.

However, the os.execute function is highly system dependent. Moreover, the celestia path and the script path
may vary from a system to another...

3- Use the new celestia:runscript() celx function that I'm about to add to celestia 1.6.1.
Indeed, Celestia already has it own runScript method which is part of the CelestiaCore class.
So I made a very simple fix by adding a couple of lines to celx.cpp so as to create the
celestia:runscript() celx function.

So all we have to do now is to wait for Celestia 1.6.1 to be released...

Chuft-Captain wrote:... Apology accepted!

...
CC

CC,

sure enough my above reply was NOT meant to be an apology!

I was rather trying to tell you that John's proposal was not OS dependent in any way, since --even in Windows-- many users would miss a lot without one-click-installing AND using one of the powerfui UNIX shells. Given my non-negligible familiarity with Lua, I was actually quite convinced that a pure Lua solution was possible and thus preferred.

I think all this was pretty well on topic, albeit seen from a more general perspective that reflected my substantial knowledge in this area.

Fridger

Thank you all for the efforts you've taken to analyze the problem. I guess we can wait til the release of 1.6.1, but in the interim, I believe there already are celx commands to take a viewer to a specific location in space, without the need to read one script from another, or to activate a cel:URL. Is it the "gotoposition" commands? I really don't know. I've tried to figure out the code, but ...

Anyway, given the celURL that I posted in the first post, is there a way to go there by activating the celURL from this post, then identifying what gotoposition code lines would be needed to go to that same position in a celx script? In this case, the time is not important.

Frank

Frank,

As far as I can analyse the CELurl, the following CELX code must do the goto position, observer orientation and many other important CELurl settings:



Hope you can use it now.
These newposition and newrotation methods at the end of the celx were especially designed to pretty easy use the given CELurl values in a CELX script.

Marco

t00fri wrote:sure enough my above reply was NOT meant to be an apology!

sure enough, I knew that.

t00fri wrote:... I was actually quite convinced that a pure Lua solution was possible and thus preferred.

I was less convinced, though hopeful, that a pure Lua solution was possible.
Anyway, it looks like Vincent's on the case now, so a solution is sure to follow.

CC

Marco and Vincent:

Marco, thank you so much for the effort you made to write a celx script that would convert my cel:URL to go to the same spot. It works just fine if I click on it separately in 1.6.0 as a single script. Sadly, when I turn on the addon within the addons folder of Lua Edu tools, the script is called OK, but the viewer doesn't go anywhere. The viewer stay still. The commands to move the viewer to the new location simply don't work.

This is most confusing, because there is a script being used in Lua Edu Tools as an addon, that does work. It is a small script for the addon, "Large Scale Universe". When I turn on that addon from within Lua Edu Tools by toggling it on in the "Set Addon Visibility" box, the script immediately activates and the viewer is whisked to a position deep in space far beyond the Milky Way. Why the position commands in this celx script work in Lua Edu Tools, and your position commands don't work, is a mystery perhaps Vincent could figure out. Here is the brief script from the Large Scale Universe:

function mark_galaxies()
for dso in celestia:dsos() do
if dso:type() == "galaxy" then
dso:mark( "white", "disk", 1, 0.6 )
end
end
end

--celestia:unmarkall()
--celestia:setrenderflags { markers = true }
--mark_galaxies()

obs = celestia:getobserver()
mw = celestia:find("Milky Way")
celestia:select(mw)

mw_dist = obs:getposition():distanceto(mw:getposition()) / (3.08e19)
mw_d = 10
if mw_dist > 50 and mw_dist < 1e3 then
mw_d = 2
end

obs:gotodistance(mw, 5.8e3 * mw:radius() / (obs:getfov() / 0.4688), mw_d) --changed from 1.1e4 to 5.8e3 to get closer to main part of clusters
celestia:setrenderflags { nebulae = true } -- added to turn on nebula

Thanks to everyone. Unless there is a way around this, i will just have to remove that addon from Lua Tools until 1.6.1. There is no use having it if the viewer cannot go to the right position to view the Hubble classes.

FYI, this is the view the addon is supposed to give the user:

Frank,

for the previous Hubble classification addon, I'm using the following script to place the user exactly where it should :

Cham:

Thanks for posting your goto script. Boy, this gets weirder and weirder. I inserted your script into the Lua Edu Tools addon, to replace the other one. It worked! When I activated the addon in Lua Edu Tools by checking the addon box in the "Set Addon Visibility" menu, the viewer actually did go out into space and get positioned in front of the hubble classes.

Unfortunately, the position one goes to ... is NOT the correct position. Rather, the Hubble classes are skewed at an angle, and they are backward (the viewer is behind them). Why running your script from inside Lua Edu Tools would bring me close to the correct place but put me in the wrong spot, is an absolute mystery.

here is the view when I click on your script directly:

Here is the view when I activate the script from within Lua Edu Tools by checking the addon check box:

Why this would occur is ...

Frank