Celestia Forums

Hello friends, this topic originates from this one:
http://shatters.net/forum/viewtopic.php?f=9&t=12925&p=108040#p108040

First of all many thanks to Chris for his green light to the project, and to Fridger, Cham and Christophe for not opposing to sound and music in Celestia, even if they don't like it.

Vincent wrote:...Andrea, could you please provide a list of the missing cel commands? That will save me some precious time.

Vincent, this is a preliminary list of cel commands that up to now are missing, IMHO:

play- (for sound-music)
overlay- (for positioning images on the screen at any position)
multiview- (to split the screen horizontally and vertically)
setlinecolor- (to change orbit lines colors, possibly with “Alpha”)
setlabelcolor- - (to change labels colors. possibly with “Alpha”)
setradius- (to change objects radius from cel script)
setgalaxylightgain- (to vary galaxy brightness)

Vincent wrote:It would be great if someone could add a cel scripting section to the Celestia wikibook, and keep it up-to-date. The cel scripting tutorial I added to the French Celestia wikibook a while ago can be a good start:
http://www.ikiru.ch/celestia/wiki/index ... s_.cel_.3F

Yes, I’ll do it following your French version, very clean and terse, but as everybody knows my English language is not as good as needed (even if I make all my best to test, correct and clean it), so surely I’ll need the help of some English mother-tongue people (Bob, will you give me your precious help, please?) for corrections and better readability.
BTW, a long time ago I asked Don Goyette if he could upgrade his very nice and useful
“.CEL Scripting Guide 1.0g”, and he asked me to make it for him, because his health didn’t allow him to do it.
Don, I hope you are better now and you are reading me, if so please confirm your approval, and I will transfer your precious work on Wiki and upgrade it where needed.

Bob, Anders, Dam. Paul, Cham, Frank, Massimo and all the other Celestians interested in education and cel scripts command improvement, will you please suggest other missing cel commands, if any?
Thank you for your help, most needed and appreciated.
Bye

Andrea

EDITED: eliminated from the list the cel commands gettrackedobject and labelsize because Chris gave them impossible with 1.6 version, alas!

ANDREA wrote:gettrackedobject- (to return the current tracked object for the observer)

But what would you do with the tracked object? There are no variables to assign values to in cel scripting, so I don't understand how this command would be used.

ANDREA wrote:labelsize- (to change font size for particular locs). Possibly applicable to locs in a single directory. I mean the possibility to have, for a self-made blablalocs.ssc locations, the labels as e.g. "sansbold20.txf" instead of "sans12.txf"- This may be very useful for example when there are not so many locs to be shown, so that they don’t clutter even if in a bigger size.

There's no support in Celestia for change the label size for individual locations, so that would have to be added before we could make a setlabelsize cel command.

--Chris

chris wrote:

ANDREA wrote:gettrackedobject- (to return the current tracked object for the observer)

But what would you do with the tracked object? There are no variables to assign values to in cel scripting, so I don't understand how this command would be used.

No Chris, sorry, surely "I" didn't understand the real purpose of that command.

chris wrote:

ANDREA wrote:labelsize- (to change font size for particular locs). Possibly applicable to locs in a single directory. I mean the possibility to have, for a self-made blablalocs.ssc locations, the labels as e.g. "sansbold20.txf" instead of "sans12.txf"- This may be very useful for example when there are not so many locs to be shown, so that they don’t clutter even if in a bigger size.

There's no support in Celestia for change the label size for individual locations, so that would have to be added before we could make a setlabelsize cel command.
--Chris

But this means that there is a possibility, correct?
Could it be added in the .cfg file?
Sorry for my scarce understanding, Chris.
Thank you for your support.
Bye

Andrea

ANDREA wrote:

chris wrote:

ANDREA wrote:gettrackedobject- (to return the current tracked object for the observer)

But what would you do with the tracked object? There are no variables to assign values to in cel scripting, so I don't understand how this command would be used.

No Chris, sorry, surely "I" didn't understand the real purpose of that command.

chris wrote:

ANDREA wrote:labelsize- (to change font size for particular locs). Possibly applicable to locs in a single directory. I mean the possibility to have, for a self-made blablalocs.ssc locations, the labels as e.g. "sansbold20.txf" instead of "sans12.txf"- This may be very useful for example when there are not so many locs to be shown, so that they don’t clutter even if in a bigger size.

There's no support in Celestia for change the label size for individual locations, so that would have to be added before we could make a setlabelsize cel command.
--Chris

But this means that there is a possibility, correct?
Could it be added in the .cfg file?

It certainly could be useful to be able to support different font sizes for location (or other labels), but there's no way to do it in Celestia right now--not in the cfg file, ssc file, or celx scripts. This is a possible feature for a later version of Celestia.

--Chris

OK, I'm finished with the addition of the missing cel commands (except play and overlay which still need to be discussed).
The changes are not in SVN yet, but Windows users can test them using the following executable:
http://vincent.gian.club.fr/celestia/ce ... eltest.exe

- setgalaxylight:

- setradius:
Only works with Solar System bodies.

- splitview / deleteview / singleview:

- setlinecolor / setlabelcolor:
- item for setlinecolor must be one of starorbits, planetorbits, dwarfplanetorbits, moonorbits, minormoonorbits, asteroidorbits, cometorbits, spacecraftorbits, constellations, boundaries, equatorialgrid, planetographicgrid, planetequator, galacticgrid, eclipticgrid, horizontalgrid, ecliptic.
- item for setlabelcolor must be one of stars, planets, dwarfplanets, moons, minormoons, asteroids, comets, spacecraf, locations, galaxies, nebulae, openclusters, constellations, equatorialgrid, planetographicgrid, galacticgrid, eclipticgrid, horizontalgrid.

Bob, Anders, Dam. Paul, Cham, Frank, Massimo and all the other Celestians interested in education and cel scripts command improvement, will you please suggest other missing cel commands, if any?
Thank you for your help, most needed and appreciated.
Andrea

Andrea, I would love to help in any way I can. That said, I am ignorant of the value of cel scripts over celx scripts. Why is it necessary to add celx commands to cel scripting? I use celx scripts to some extent, and they work fine. When I want to run a cel script, I just embed it inside the celx script. I know very little about scripting, so please someone explain the difference ...

Thanks

Frank

fsgregs wrote:

Bob, Anders, Dam. Paul, Cham, Frank, Massimo and all the other Celestians interested in education and cel scripts command improvement, will you please suggest other missing cel commands, if any? Thank you for your help, most needed and appreciated.
Andrea

Andrea, I would love to help in any way I can. That said, I am ignorant of the value of cel scripts over celx scripts. Why is it necessary to add celx commands to cel scripting? I use celx scripts to some extent, and they work fine. When I want to run a cel script, I just embed it inside the celx script. I know very little about scripting, so please someone explain the difference ... Thanks. Frank

Frank, the problem is simply this: for many people like me celx scripting is too much difficult, because it is way less user-friendly than cel scripting, or at least less intuitive.
I mean that if I want a certain action to be executed, cel needs just one, two, maximum three simple lines, while celx needs many and more complex ones.
Cel commands are easily memorisable (they are not so many), differently from celx (unless, obviously, one uses very often this language, in practice what happens or happened for Linux OS that, even if it's way better than any Windoze OS, still doesn't obtain the favour it deserves.

Obviously I agree that celx scripting allows many things that are impossible with cel, e.g. movements fluidity, but on the other side there is a big difficulty to use it for poorly trained people.
Regarding the embedding of cel scripts within celx scripts, documentation on what's needed to be written on top and bottom of the cel script is very poor, if any, IMO, so a kind of template would be very appreciated, e.g. like the one in start.cel script.
Cel language was the only one for a long time, accepted, learned and used by many people, and now that there is the possibility to maintain and improve it, partly following celx new commands, we would like to have it in Celestia core, no more as a patch.
Chris agreed on this, and Vincent is very kindly adding the new commands for 1.6 final release (many thanks to both of you!).
So I’m asking everybody’s help to find what celx commands, actually without twin in cel scripting, could be helpful in cel too, and I asked your help because I well know your interest and experience in educational projects.
Bye and thank you.

Andrea

Hello Vincent, beg your pardon for the long time from your celestia-test realease.
I have my older daughter’s marriage on Oct 4th, so I’m ranting after my wife and my two daughters from one shop to another… a terrible experience!
Well, finally I had some free time, so I checked your new exe using this modified start.cel:

{
set { name "RenderPath" value "vp-nv" }
setvisibilitylimit { magnitude 6.5 }
renderflags { clear "orbits|constellations|comettails|boundaries|galaxies|ringshadows" }
renderflags { clear "eclipseshadows|pointstars|nightmaps|markers|cloudmaps" }
renderflags { set "stars|planets|galaxies|orbits|"}
unmarkall { }
labels { clear "comets|constellations|galaxies|stars|planets|moons|spacecraft|asteroids|" }
labels { set "planets" }
set { name "FOV" value 35.0 }
orbitflags { set "planets" }
set { name "AmbientLightLevel" value 0.6 }
timerate {rate 20000.0}
set { name "MinOrbitSize" value 0.05 }
select {object "Sol"}
center {}
goto {time 3.0 distance 6}
wait {duration 4.0}
follow {}
select {object "Sol/Earth"}
center {}
goto {time 4.0 distance 6}
wait {duration 5.0}
follow {}
setlinecolor { item "planetorbits" color [0.3 0 0] }
wait {duration 6.0}
setlabelcolor { item "planets" color [1 0.1 0.1] }
wait {duration 6.0}
setradius {object "Sol/Earth" radius 2000}
wait {duration 6.0}
select {object "M 33"}
set { name "FOV" value 2.0 }
goto {time 4.0 distance 90}
wait {duration 5.0}
setgalaxylight {gain 0.40}
wait {duration 5.0}
setgalaxylight {gain 0.25}
wait {duration 5.0}
setgalaxylight {gain 0.10}
wait {duration 5.0}
set { name "FOV" value 28.0 }
goto {time 4.0 distance 4}
wait {duration 5.0}
splitview {type "h" position 0.5}
wait {duration 5.0}
splitview {type "v" position 0.5}
wait {duration 5.0}
splitview {type "v" position 0.5}
wait {duration 5.0}
deleteview {}
wait {duration 5.0}
deleteview {}
wait {duration 5.0}
singleview {}
wait {duration 8.0}
}

Here the results:
1- setlinecolor: it’s perfect, and the result is very nice;
2- setlabelcolor: it have a strange behaviour, because while the planets names are correctly shown in pure red (image #1), the locations are still in green color;
3- setradius works OK, but there is a strange behaviour once again, because the locations radii stay fixed, so we see them well over the planet Earth, in my example (image #2). Don’t know if this is a normal thing or not;
4- setgalaxylight: it’s perfect;
5- splitview: I fear it needs a different approach, and I’ll try to explain the reason of this: in my example I ask to split first once horizontally and then twice vertically, and I supposed this would be resulting in the example image#3, i.e. the screen divided in four equal images, but it’s not so. After the first horizontal split, it splits vertically the bottom image, and the second vertical split command splits vertically the bottom left one, as you can see in image#4. I think that the images should gain a number, as produced, following e.g. the left-right-top-bottom rule. This way we could give the following commands:
splitview {type "h" img 1 position 0.5} # (img 1 is the full screen, that now is splitted horizontally in img1-top and img2-bottom)
splitview {type "v" img 1 position 0.5} # (now img 1-top is splitted vertically in two, that will be now img1-topleft and img2-topright, while the former img2-botom becomes img3-bottom)
splitview {type "v" img 3 position 0.5} # (now img 3bottom is splitted in two resulting images, respectively img3-bottomleft and img4-bottomright)
Anyway we can obtain the same thing, manually clicking on the images one wishes to split, following the cel commands sequence. In the above example, I have to click first the top image then, after this has been splitted, the bottom one. Not elegant, but it works. But this doesn’t allow the most important effect using cel script, i.e. the possibility to put in the various screens the object I like, using cel command. E.G, after splitting the screen in four, positioning in them the single four Galilean moons, seen from the same distance, to show their size and behaviour differencies.
The image#4, showing how the splitting works actually, is shown in the next post, due to the stange (and useless, IMHO) lim1t of three images/post.
Sorry to trouble with this, Vincent, and thanks a lot for all what you are doing here.
Bye

Andrea

Here the fourth image, showing the actual splitting behaviour
Bye and thank you, Vincent.

Andrea

ANDREA wrote:2- setlabelcolor: it have a strange behaviour, because while the planets names are correctly shown in pure red (image #1), the locations are still in green color;

This is the expected behaviour. To change the color of labels, you need to add:
setlabelcolor { item "locations" color [1 0.1 0.1] }

Andrea wrote:3- setradius works OK, but there is a strange behaviour once again, because the locations radii stay fixed, so we see them well over the planet Earth, in my example (image #2). Don’t know if this is a normal thing or not;

I'll have a look at this...

Andrea wrote:5- splitview: I fear it needs a different approach, and I’ll try to explain the reason of this: in my example I ask to split first once horizontally and then twice vertically, and I supposed this would be resulting in the example image#3, i.e. the screen divided in four equal images, but it’s not so. After the first horizontal split, it splits vertically the bottom image, and the second vertical split command splits vertically the bottom left one, as you can see in image#4.

I was suggesting Chris to add a 'view' argument to the deleteview() method, such as:

I think that adding this argument to the splitview command too would solve the problem:

Vincent wrote:

Andrea wrote:3- setradius works OK, but there is a strange behaviour once again, because the locations radii stay fixed, so we see them well over the planet Earth, in my example (image #2). Don’t know if this is a normal thing or not;

I'll have a look at this...

Location positions are computed relative to the center of the object when they're created. If you want to change their positions when the planet's radius is adjusted, you would need to multiply the coordinates of each location by newRadius/oldRadius. This assumes that you want location altitude to scale with radius, which is what you should do if you want, say, ring location labels to remain in the right place.

Note that changing the radius of a planet with a script will not have any effect on the positions of objects placed its surface with either LongLat or the new FixedPosition modes. If you increase the radius of Mars with a script, you'll find that the Mars rovers are inside the planet. Hopefully this isn't a problem for you usage of setradius. No trajectory types--fixed positions, elliptical orbits, or anything else--get scaled with planet radius.

--Chris

Vincent wrote:

ANDREA wrote:2- setlabelcolor: it have a strange behaviour, because while the planets names are correctly shown in pure red (image #1), the locations are still in green color;

This is the expected behaviour. To change the color of labels, you need to add:
setlabelcolor { item "locations" color [1 0.1 0.1] }

Oops! I forgot adding this line, sorry.
Shame over me!

Vincent wrote:

Andrea wrote:3- setradius works OK, but there is a strange behaviour once again, because the locations radii stay fixed, so we see them well over the planet Earth, in my example (image #2). Don’t know if this is a normal thing or not;

I'll have a look at this...

OK, but after Chris explanation I think we can stay with your actual solution, IMO it’s not worth modifying it to obtain the radii change of all the locations, objects, etc. that are over or close to the surface.

Vincent wrote:

Andrea wrote:5- splitview: I fear it needs a different approach, and I’ll try to explain the reason of this: in my example I ask to split first once horizontally and then twice vertically, and I supposed this would be resulting in the example image#3, i.e. the screen divided in four equal images, but it’s not so. After the first horizontal split, it splits vertically the bottom image, and the second vertical split command splits vertically the bottom left one, as you can see in image#4.

I was suggesting Chris to add a 'view' argument to the deleteview() method, such as:

Code: Select all

deleteview {view 2} # delete view n°2 = 2nd view created

I think that adding this argument to the splitview command too would solve the problem:

Code: Select all

splitview {type "h" position 0.5}
wait {duration 5.0}
splitview {type "v" position 0.5 view 1}
wait {duration 5.0}
splitview {type "v" position 0.5 view 2}

Yes, probably this is the way to solve it.
And, if e.g. I wish to show all the eight planets and the Sun on nine different screens, it looks a bit more complicate, but feasible.
After the execution of the above lines, we have four screens (but how are them identified? 1-2= Top left-right, 3-4= bottom left-right?), and now we are missing another command like
selectview { view 1}
that from .cel script can address the following commands (goto, or changedistance, or whatever else) to one of the open screens, e.g.


This will allow the full use of splitview, IMHO.
Opinions?
Bye and thanks a lot, Vincent.

Andrea

chris wrote:

Vincent wrote:

Andrea wrote:3- setradius works OK, but there is a strange behaviour once again, because the locations radii stay fixed, so we see them well over the planet Earth, in my example (image #2). Don’t know if this is a normal thing or not;

I'll have a look at this...

Location positions are computed relative to the center of the object when they're created. If you want to change their positions when the planet's radius is adjusted, you would need to multiply the coordinates of each location by newRadius/oldRadius. This assumes that you want location altitude to scale with radius, which is what you should do if you want, say, ring location labels to remain in the right place.

Note that changing the radius of a planet with a script will not have any effect on the positions of objects placed its surface with either LongLat or the new FixedPosition modes. If you increase the radius of Mars with a script, you'll find that the Mars rovers are inside the planet. Hopefully this isn't a problem for you usage of setradius. No trajectory types--fixed positions, elliptical orbits, or anything else--get scaled with planet radius.
--Chris

Thank you for explanation, Chris.
Following it I think we can stay with the actual solution, IMO it’s not worth modifying it to obtain the radii change of all the locations, objects, etc. that are over or close to the surface.
I think the planet radii variation may be enough.
Thanks a lot.
Bye

Andrea

ANDREA wrote:And, if e.g. I wish to show all the eight planets and the Sun on nine different screens, it looks a bit more complicate, but feasible.
After the execution of the above lines, we have four screens (but how are them identified? 1-2= Top left-right, 3-4= bottom left-right?)

The views are indexed according to the order of their creation. In my example above, we would have:
-> View #1 : bottom
-> View #2 : up

-> View #1 : bottom left
-> View #2 : up
-> View #3 : bottom right

-> View #1 : bottom left
-> View #2 : up left
-> View #3 : bottom right
-> View #3 : up right

ANDREA wrote:and now we are missing another command like
selectview { view 1}
that from .cel script can address the following commands (goto, or changedistance, or whatever else) to one of the open screens

I agree that this would be a useful command, and so does Chris.
Since it is also missing in celx scripting, I'll add it both to cel and celx.

Vincent wrote:

ANDREA wrote:And, if e.g. I wish to show all the eight planets and the Sun on nine different screens, it looks a bit more complicate, but feasible.
After the execution of the above lines, we have four screens (but how are them identified? 1-2= Top left-right, 3-4= bottom left-right?)

The views are indexed according to the order of their creation. In my example above, we would have:

Code: Select all

# Split single view 1 horizontally
splitview {type "h" position 0.5}

-> View #1 : bottom
-> View #2 : up

Code: Select all

# Split view 1 vertically
splitview {type "v" position 0.5 view 1}

-> View #1 : bottom left
-> View #2 : up
-> View #3 : bottom right

Code: Select all

# Split view 2 vertically
splitview {type "v" position 0.5 view 2}

-> View #1 : bottom left
-> View #2 : up left
-> View #3 : bottom right
-> View #3 : up right

OK Vincent, all clear now, thank you.

Vincent wrote:

ANDREA wrote:and now we are missing another command like
selectview { view 1}
that from .cel script can address the following commands (goto, or changedistance, or whatever else) to one of the open screens

I agree that this would be a useful command, and so does Chris. Since it is also missing in celx scripting, I'll add it both to cel and celx.

This is a very good news, thank you both, very appreciated.
Bye

Andrea

The following CEL scripting commands are now part of Celestia 1.6:
- setradius
- setgalaxylightgain
- setlinecolor, setlabelcolor
- splitview, deleteview, singleview, setactiveview

Here is an script-example that uses splitview, deleteview, singleview and setactiveview:


Windows users can get Steve's SVN build to test these new scripting features:
http://cartrite.myhosting247.com/index.html

Just wait for revision 4445...

Vincent wrote:The following CEL scripting commands are now part of Celestia 1.6:
- setradius
- setgalaxylightgain
- setlinecolor, setlabelcolor
- splitview, deleteview, singleview, setactiveview
Windows users can get Steve's SVN build to test these new scripting features:
http://cartrite.myhosting247.com/index.html
Just wait for revision 4445...

Thanks a lot, Vincent, I'll try the new commands as soon as SVN 4445 will be available from Cartrite.
Any news on sound-images in cel scripts?
Bye and thank you once again.

Andrea

Vincent wrote:The following CEL scripting commands are now part of Celestia 1.6:
- setradius
- setgalaxylightgain
- setlinecolor, setlabelcolor
- splitview, deleteview, singleview, setactiveview
Windows users can get Steve's SVN build to test these new scripting features:
http://cartrite.myhosting247.com/index.html
Just wait for revision 4445...

Hello Vincent, as promised, I downloaded the r4445 (thank you Steve! ) and checked it with your .cel script, with just a change on the objects, that here are the Galilean Jupiter moons seen at the same distance to show their different dimensions.
As you can see in the first image, it works very well.
Then, just to play, I increased the distances to show the Milky Way in various shapes, and here I found something I was not aware of.
Look at the second image… the splitting looks a bit strange, isn’t it?
Well, that image splitting has been obtained with the same 0.5 splitting of your cel script, but
the screen sizes have been modified manually by me, putting the cursor on the lines and left-clicking and moving it at will.
I don’t know if this was an already known capability, but it’s very nice and useful, IMHO.
Just FYI.
Thanks a lot, Vincent.
Bye

Andrea

ANDREA wrote:Well, that image splitting has been obtained with the same 0.5 splitting of your cel script, but
the screen sizes have been modified manually by me, putting the cursor on the lines and left-clicking and moving it at will.
I don’t know if this was an already known capability, but it’s very nice and useful

We had this capability since a very long time. If I remember, it was there since the very first time I used Celestia, several years ago.

Cham wrote:

ANDREA wrote:Well, that image splitting has been obtained with the same 0.5 splitting of your cel script, but
the screen sizes have been modified manually by me, putting the cursor on the lines and left-clicking and moving it at will.
I don’t know if this was an already known capability, but it’s very nice and useful

We had this capability since a very long time. If I remember, it was there since the very first time I used Celestia, several years ago.

Doh!
OK, so I didn't discover it.
But, just curious, was it announced and/or discussed somewhere?
If yes, I missed it, even if I'm in Celestia almost from its beginning.
Thank you for the info, Cham.
Bye

Andrea