Yep, it's probably obvious how my buttons work, but a uv-toggle-off/on can have any string attached to it, so my buttons for slides, layers and objects all look very similar and are just the custom command string, with one consistent javascript control, but it doesn't automatically scale, as it looks like yours might be intended to? I still have to hand-make each button (lots of copying and pasting).

Hey Ka Chun,

If it's of any help, I an attach html an example of a now-fully functional HTML page from one of our shows in Uniview 2.0.

They're still not idea, fancy page layouts, but it might be helpful. Instead of scripting each individual layer button, I have a generic "toggle" type button that alternates between two clasess (uv-toggle-off and uv-toggle-on) which enables to send it two different command strings, which has made it easier (and less programming intensive and consistent) to toggle resources in Uniview in our custom layouts. All the javascript is still stored in the uniview.js.

If it's of interest, I have not put this on UCare, but for our own season presentations we made large, 3D poles:

https://www.hightail.com/download/UlRUQ1Z1ZDV1Yk53SGNUQw

You can download the module there. If you would like to change the color of the poles, you can replace the "stripes.png" file with any file of the same name. We used green & orange "Academy" colors, but you could switch to red and white just by deleting it and renaming "stripes old." We felt this had visibility advantages over the basic lines.

Dan

I was in need of this exact information myself building a show this week.

Using the Sun Detail, the cutplane information can be found in the statemanger (gui.statemanger in the custom commands window to open) under SunDetail_Effect.

To activate the cutplane: SunDetail_Effect.prop.cutplane 1 3 will move the cut plane to full depth over 3 seconds. The value is a float value, not a boolean, from what I can see, allowing for variable depth of cut.

Unlike most other objects in Uniview, this one seems to be case-sensitive.

I've also found that if I do
camera.flyto location -122.4662 37.7707 (CAS, which I notice is not on the list of Uniview installs!) it flies me to somewhere around Indiana, whereas if I do
camera.jumpto location -122.4662 37.7707 it correctly takes me to the Academy.

And what should that look like for a user-added named location?

So if I understand, per the documentation and my tests, to flyto location I still need to only do long/lat, and I can't specify the location by name, yeah?

And yes, we're putting together a show on celestial navigation right now. It'd be great to be able to build commands that let us smoothly slide up towards the pole or the equator while in sky mode, rather than just jumping between them.

Thank you, yes, it all works, and I was able to apply the same change to the toggle button to make it work as well.

Dan

spicekernelorbitconstruction.docx

Since this reminded me to finally write a guide for our reference here at CAS on working with kernel based orbits, I thought I'd provide it here too... although sorry it's not totally proofread yet. This lengthy document will hopefully walk one through the creation of most SPICE kernel based trajectories. It's still not an easy process, but hopefully I break it down step-by-step for anyone who wants to try. Otherwise, I guess you can keep just waiting on me to build the modules for you :).

Greg, if this seems useful, is there another good place to put it on UCare?

I always use JPL HORIZONS for orbit data http://ssd.jpl.nasa.gov/horizons.cgi which lists "DailyMotion" as "N" in degrees. It's also important to make sure you have the right period in the orbit.conf file. If it's too long, it will loop back on itself, if it's too short, it will cut across itself (PR on HORIZONS in days, although I'll convert to hours when appropriate). Also important to make sure that the orbit is tied to the right object in the .mod file (this is declared in the coordinate system, but needs the name of the object). This is another place DateofElements is important, because of kepler's 2nd law.

Also as a general tip for those less familiar with orbital elements who might be reading this: Uniview (and every other planetarium program I've worked with) needs the longitude of the ascending node, longitude of the periapsis (or perihelion or perigee, periapsis is the generic term) and mean longitude. HORIZONS and most other services provide the longitude of the ascending node (OM), argument of the periapsis (W) and mean anomaly. Longitude of the periapsis is the longitude of the ascending node + argument of the periapsis (OM+W) and then mean longitude is the longitude of the periapsis + mean anomaly (OM+W+MA). When numbers exceed 360, you can subtract 360 (or not, Uniview doesn't care).