Realistic stars, the return...

[Knotty]

Hi,
Returning to OoLite after a break, have updated Realistic Starts oxp to the new OXZ format and posted it to the list. (no other changes, enjoy)

However, having a quick look at the JavaScripting, wondered if it would be possible to vary the number of stars (sky_n_stars) based on the current location, or systemsInRange.
I'm guessing System.info.sky_n_stars="whatever" would be the property i need to set, but I've seen mention on the forum that it does vary out of the box. Should I be setting star_count_multiplier and how does this work? (i.e what is it multiplied against)

Thanks

[Smivs]

Welcome back Knotty
Can't help with the stars though...

[cim]

However, having a quick look at the JavaScripting, wondered if it would be possible to vary the number of stars (sky_n_stars) based on the current location, or systemsInRange.
I'm guessing System.info.sky_n_stars="whatever" would be the property i need to set, but I've seen mention on the forum that it does vary out of the box. Should I be setting star_count_multiplier and how does this work?

sky_n_stars sets a fixed number of stars. You can set this per-system in planetinfo.plist rather than as a universal value. (You could also set it with Javascript, but it would be better in planetinfo.plist)

star_count_multiplier multiplies the default (variable) number of stars in the system by a particular value. (2400 * star_count_multiplier * 0..1 * 0..1) The two 0..1 vary from system to system. If sky_n_stars is set >= 0 for a particular system (either in the system data or in universal) this value is ignored.

The problem with star_count_multiplier is that no matter how high you set it, in some systems one of those two random numbers will come up as almost 0 (or even exactly 0) and you'll get no stars at all. So sky_n_stars is better if you want to have a particular number, even though you have to do the variation yourself.

(Oh, and if the graphics settings are turned right down, star count is capped at 2400 whichever way you set it)

[Knotty]

Thanks
There's a fair amour of systems, so a calculated value set using JS would potentially be easier than working them all out, although if the processing overhead is to great for some machines, I'll have to do it.
Can I detect the graphics settings from JS?

[Cody]

The problem with star_count_multiplier is that no matter how high you set it, in some systems one of those two random numbers will come up as almost 0 (or even exactly 0) and you'll get no stars at all.

This drives me crackers - occasional systems with few or no stars.

[Zireael]

The problem with star_count_multiplier is that no matter how high you set it, in some systems one of those two random numbers will come up as almost 0 (or even exactly 0) and you'll get no stars at all.

This drives me crackers - occasional systems with few or no stars.

Me too!

[another_commander]

Can I detect the graphics settings from JS?

Yes. oolite.gameSettings.detailLevel is what you need.

For reference, if you type oolite.gameSettings in the debug console, it gives you the list of game properties you can access. Some are read/write, some All are read only. Here it is:

autosave: 0,
wireframeGraphics: 0,
procedurallyTexturedPlanets: 1,
detailLevel: "DETAIL_LEVEL_EXTRAS",
musicMode: "MUSIC_ON",
speechOn: 0,
gameWindow: {
fullScreen: 0,
height: 600,
width: 800
},
keyConfig: {
key_prime_equipment: 78,
key_scanner_unzoom: 90,
key_galactic_hyperspace: 103,
key_inject_fuel: 105,
key_roll_left: 253,
key_next_compass_mode: 92,
key_gui_chart_screens: 54,
key_view_aft: 50,
key_roll_right: 252,
key_rotate_cargo: 82,
key_prev_compass_mode: 124,
key_previous_target: 45,
key_chart_highlight: 63,
key_view_forward: 49,
key_map_home: 303,
key_dump_target_state: 72,
key_jumpdrive: 106,
key_mode_equipment: 98,
key_docking_clearance_request: 76,
key_show_fps: 70,
key_yaw_left: 44,
key_gui_arrow_up: 255,
key_activate_equipment: 110,
key_view_starboard: 52,
key_untarget_missile: 117,
key_custom_view: 118,
key_scanner_zoom: 122,
key_cycle_mfd: 59,
key_gui_market: 56,
key_yaw_right: 46,
key_comms_log: 96,
key_hud_toggle: 111,
key_pitch_forward: 255,
key_snapshot: 42,
key_mouse_control: 77,
key_weapons_online_toggle: 95,
key_gui_system_data: 55,
key_pitch_back: 254,
key_ecm: 101,
key_gui_arrow_down: 254,
key_dump_cargo: 68,
key_docking_music: 115,
key_view_port: 51,
key_fire_lasers: 97,
key_fastactivate_equipment_a: 48,
key_switch_mfd: 58,
key_fastactivate_equipment_b: 9,
key_increase_speed: 119,
key_hyperspace: 104,
key_decrease_speed: 115,
key_gui_screen_status: 53,
key_ident_system: 114,
key_gui_arrow_left: 253,
key_map_info: 105,
key_advanced_nav_array: 94,
key_next_missile: 121,
key_gui_arrow_right: 252,
key_launch_escapepod: 27,
key_pausebutton: 112,
key_target_missile: 116,
key_launch_missile: 109,
key_target_incoming_missile: 84,
key_next_target: 43,
key_autopilot: 99,
key_autodock: 67
}

[Knotty]

Thanks!
Hmm, what to take into account...
DetailLevel obviously, TexturedPlanets possibly, Screen size?
I wonder if I could turn the stars into ascii * when wire frame is turned on....

Was thinking about near no stars for systems with only one connection, or on the outskirts of a galaxy. Guess from the feedback before I start that there should be a minimum value

[Cody]

Was thinking about near no stars for systems with only one connection, or on the outskirts of a galaxy.

In a system that had both those qualities, such as Ceered in the fifth octant, few (or even no) stars would perhaps suit.

[mossfoot]

The problem with star_count_multiplier is that no matter how high you set it, in some systems one of those two random numbers will come up as almost 0 (or even exactly 0) and you'll get no stars at all.

This drives me crackers - occasional systems with few or no stars.

So it's not just me! I was wondering about that!

[Diziet Sma]

G'day Knotty.. good to see you again..

<hoping you'll do the OXZ for the Sensible Suns version of RS soon - or better yet, combine them in one package>

[Knotty]

AH, yes, Sensible suns, forgot about that....
Well, if I'm getting into scripting there's a tutorial about dependencies.. it's for script dependencies, but I'll see if I can just detect if it's there. Plan B is 2 separate ones again, however as Sensible suns doesn't have a OXZ I do't think I can tell the manifest that theres a clash (if I understand this correctly)
http://wiki.alioth.net/index.php/Handli ... JavaScript

[mossfoot]

Just want to say, I love this add-on, but I have one problem with the results, though I don't know if this app can fix it or if another one will be required.

Every planet's dark side is... well... dark! It's so pitch black you can't see anything. And that wouldn't be a huge problem if it weren't for the fact that these planets are all fairly well populated in the billions so we should be seeing something more like this:




Assuming that's not possible, perhaps dialing back the black so it's at least dully visible to compensate? Have that as an option in the OXPConfig?

[Wildeblood]

Sensible Sun doesn't have a OXZ I don't think I can tell the manifest that there's a clash.

Sure you can. If and when I ever make Sensible Sun into an OXZ, it's identifier would be oolite.oxp.Wildeblood.sensible_sun

To detect Distant Suns (which again only affects sun_* settings, not the background sky, and doesn't change any universal settings) from a script you can check for the presence of worldScripts.Stars. All the settings are changed with a giant planetinfo file, but Stars is the snippet of script that adds the note to the F7 screen.

[Zireael]

Mossfoot, I love that picture!