Planetfx to turn it off or moon.planetfx gamma [value], values <1 will make it brighter.

This still isn't really satisfactory since we do want to demo it from sky mode and also want to automate a lot of it through scripting (so not having to manually ctrl+click the navigation button).

In general it'd also be really great to improve Uniview's reliability beyond 1600-2200ish and/or clarify Gergorian/Julian conversion. For example, we are preparing a show on eclipses and had to do some fakery to get Columbus' Feb 29 1504 lunar eclipse to work. We have been totally unable to do the -584 Eclipse of Thales (the moon seems to be every slightly off)

Here's a video from other software demoing what I'd like to be able to do: https://www.dropbox.com/s/qt92z7cpxpkcz36/precession.mp4?dl=0

I don't leave the surface, stay locked on 0 RA. In one version I turn of the sun and planets to avoid their distraction and we can see the constellations roll around 0RA. In the other I turned it back on and we see the sun go around. Since in UV even with daily motion off (aka annual motion on) we still have the Earth's annual motion around the sun there's no getting around the constantly whipping around effect.

It's possible, from orbit mode (with the Earth off) to lock to a constellation/planet and watch this effect. There is also a retrograde motion module in the community content area that ay help with this. As with your other question, I also do this with stepping by sidereal days to keep the stars still while letting other objects move. There was a thread about this on the users group a while ago too that may have more answers.

This is exactly how I do it too.

Oh, I was requesting documentation, since none exists. This is very helpful, thank you.

So the first magnitude value should really be the maximum visual magnitude of the planet (in which case, many of the planets are too low), or is that just the name of the variable? And then the second variable is minimum distance from Earth?

I guess I'm interested in how to get a behavior that predictably responds somewhat like the real planets. It seems like this will provide the core of that as long as everything is clear and straightforward. My only other note is making maxpointsize too big seems to leave the point up when flying to the planet, but there's not really a distancefade setting here?

So, I think you shouldn't change anything in the .cmap file. The CMAP is literally
R G B Alpha as values/1.0 and sometimes with a comment. Uniview takes the cmap and the number of entries and creates a linear gradient between the values.

I mean, depending on how basic this should get:

B-V color is literally the magnitude of a star through a blue filter (B) minus the magnitude of a star through a visible/greenish filter (V). Negative values are bluer, positive values are redder, and this has a known relationship between temperature and color.

In the case of these star files, we compiled them from different sources--AMNH used XHIP (Extended Hipparcos), Ka Chun used Hipparcos and Yale Bright Star Catalogue, I used XHIP, Gliese-Jahreiss with some additional Aladin XMATCH to fill it out from various other catalogues.

I assume Ka Chun was doing the same thing I was doing: Hipparcos on its own has some missing b-v data for stars that is available in other surveys, which affects even some naked-eye stars. So if you can cross-reference it, you can fill in these values--this is why denver_stars and cas_stars are both larger than amnh_stars--AMNH appears to have just dropped stars that had missing values.

What I observed, however, is that for these troubled red stars in Ka Chun's catalogue, they seem to just have the B magnitude entered, not B-V. But other stars are correct. So for a star like Betelgeuse, it's b-v should be something like 2.3 Bmag - 0.8 V Mag = 1.5 B-V (since Ka Chun used Tycho, his value would actually be more like 1.8, I think). Instead, because 2.3 is the value entered for Betelgeuse in the speck file, it shows up as redder than it should be. Same for Arcturus, and presumably all the other troubled stars.

(b-v isn't missing from Hipparcos or Tycho from these stars, it looks like a transcription error in creating denver_stars)

denver_redstars fixes in a kind of brute-force way by changing the cmap for just these, but doesn't correct the innate problem in the speck file.

In summary you SHOULD NOT change the cmap for denver_stars as a whole, because it'll throw off many of the correct values for stars throughout, since you'll be expanding the range of the colormap--your yellow stars will redden, which would not look good!

Since they should have similar accuracy, unless Ka Chun is looking to update denver_stars, I think you could get the same look by using the same slum, polysize, pointsize etc, settings from denver_stars in CAS_stars, editing the .mod file. I think a few of us are also working on a Gaia/Tycho/Hipparcos merge, which will increase the number of stars by 20x and should replace the existing star modules anyway.

Hey, I was just looking at this because it seems like a good question to answer...

Both Ka Chun and I are using a Mitchell Charity derived color-map, so the stars should be very similar in color, and we use a similar range for the colormap. However, spotchecking in the speck files, in denver_stars, Betelgeuse has a B-V value of 2.32; in CAS_Stars it has 1.5. I built mine from XHIP, and this is consistent with that. I saw that you also built DMNS from Yale Bright star and Hipparcos--Yale gives 1.85 for Betelgeuse's B-V (consistent with Johnson 1966), and it's 1.5 in Hipparcos, Tycho and XHIP. 2.32 looks like just the B value. Is it possible some of the red stars in DMNS stars have the wrong B-V value? In cases like Betelgeuse a value of 2.32 would overrun the colormap and be drawn very red (much redder than the colormap suggests) creating this issue. Checking redstars, a lot of the red stars do seem to have B-V values greater than 2.0 (maximum in the colormap). Antares seems to be in the same situation--its B mag is given for B-V, so it's almost a value of 1 too high. Is it possible a chunk of the red stars were done incorrectly? Most other stars look fine, it seems like it might just be a selection of bright, red stars.

The only way to do this would be to adjust the colormap file to assign different values for the b-v colors.

May I suggest CAS stars as an alternative, which has a well researched color-map? SLUM and polysize can be adjusted to match DMNS_Stars, or the cmap could be replaced (but I would not be able to guarantee the accuracy).

Thanks, I'll play around with this!