Split: Re-scaling experiment

[Redspear]

(Not tested).

Tested. Works

Hmm... what if there was a distance check? Suppose names only displayed at sufficient distance to avoid overlap...

[Redspear]

Is OOPlanetEntity no longer scaling suns along with planets? I note the radius is recorded differently for stars in planetinfo.plist, is it necessary to edit them all by hand? ...

Looked into this. There's a line to scale them in OOSunEntity.m but it is overwritten by the values in planetinfo.plist.
Biggest star according to planetinfo.plist seems to be at Ontesoge: sun_radius = 233842.365417, max star size is 1,000,000 (I believe), so sun_radius * 4.25 (or 3.3 if it's better to leave some spare room) would be a good multiplier for an oxp script (or so I thought) but the radius is read-only via oxp.

Short term fix: find and replace all instances of "sun_radius" with "// sun_radius", this allows me to set star/sun size in a similar manner to previous versions of the experiment.

Better way might be to either make sun_radius read/write or multiply the each of the sun_radius values directly into planetinfo.plist.
BTW, according to the wiki, universal settings should be overwritten by individual settings. In some cases at least however, it appears to be the other way around.

In any case, big suns are back

[zevans]

Aha - I am knocking together a Python script to do these multiplications in planetinfo.plist - I thought that might radically speed up your experiments!

[Redspear]

I thought that might radically speed up your experiments!

Awesome

That way sun size would/could be independant from planet size, therefore granting greater system variation.

[Redspear]

Sun Bathing Testing

So, it isn't in OOSunEntity but OOPlanetEntity that sun radius is set. That means sun radius increases proportionally to planet radius.
I thought a sun distance of x5 looked good before, so with larger suns that's now a sun distance of x 33. Masslock needs adjusting of course but I'm nearly there with that.

Editing (rather than disabling) the planetinfo.plist sun radius settings is a little problematic in that a max universal multiplier would be approx 4.25. that would make a significant difference over x1 but with planets at x6.6 any less than that value is likely to be unsatisfactory.

Larger suns have a larger corona which can be helpful in terms of making their apparent size (and that of the nearby planet) less obvious. Once again, the goal of this experiment has never been realism but rather misdirection e.g. the station is still far too big for the planet but let's no longer make it visible enough to be clearly seen next to the entire planet.

Re ambient light...
Launching to face the dark side of a planet is (literally) rather dull, even in the core game it's virtually pitch-black. Ships can be hard to find (stations too in the rescaled version) and increasing sun distance doesn't help in this regard. Base value is 0.1 but I'm finding that something around 0.6 is good - the dark side of anything is still dark but no longer purely black and featureless.

So, currently:

• Sun & Planet Radius x6.6
• Sun Distance Modifier x33
• Torus drive x8 (gotta cover those distances somehow - value is smaller than x33 because torus drive scales with distance)
• Ambient Light x6

There may be mission related consequences to sun changes but this is standard game stuff, visible every time. Besides (said with the confidence of one who doesn't have to do it) it should be largely a maths adjustment for the mission I'm thinking of.

[another_commander]

I find that ambient light at 0.6 is huge. Keep in mind that 0.6 in one system may not look the same as 0.6 in another.

[Redspear]

Good point.

If we can assume shaders then I could try your suggestions up thread.
However, given that the core game doesn't, neither have I.

EDIT: also it probably looks different in the environment I'm using compared with the core game...

[Redspear]

By no means a thorough comparison but here's what station traffic looks like at Isinor with ambient light set to 0.1 compared with a setting of 0.6

Disclaimer: this is presented merely as evidence, not as proof.
Please feel free to post (or suggest) alternative evidence so that a more comprehensive or fair comparison can be made.

Settings: Extra Detail
Shipset: Default (no shaders)

0.1 then 0.6...

View upon launching






Scenic view






Python docking






Cobra 3 docking






In shadow






This is very much a case of your mileage may vary but ignoring for the moment variables such as eye-sight and monitor quality/usage...

• Nothing has been shrunk here - the python and station are twice as big but that's how a mk3 usually looks at that range
  (check the scanner distance for a standard game comparison)
• Planet surface is almost invisible at 0.1 compared to faint at 0.6
• Ship visibility is surprisingly similar but significantly different when in full shadow

Some of my earlier (but recent) pics on this thread were with ambient light set as high as 1.0. That's too high I think but it's a shame that I didn't let that python at 0.6 roll to a comparable angle as the one at 0.1 as visibility is improved somewhat, even at 0.6.

[zevans]

Code: Select all

planet_plist_ops = {
        "planet_distance": " * 6.6",       # Planet to Witchpoint
        "sun_distance": " * 1",            # Planet to Sun
        "sun_distance_multiplier": " * 1", # > 1.81 and only if _modifier not set
        "sun_distance_modifier": " * 1",   # <= 1.81. Is this deprecated?
        "radius": " * 1",
        "sun_radius": " * 1",
        "corona_flare": " * 1"
        # TODO: rotation velocities
}

So my hacky Python sort of works. At the moment it sometimes writes the file back in a different order, and trashes the whitespace in the file too. The game still works with the generated file though, despite those cosmetic formatting changes. (Also I learned how many fun kinds of plist there are, including the fact that OpenStep and NextSTEP are different in this regard.)

Have you got good values for all of these multipliers that I have set to "* 1" at the moment? I can then generate us a .plist for testing once and for all and stick it on my fork on github.

I think it's worth changing the sun_distance in the base, because that way OXPs that rely on the _multiplier or the _modifier will operate on your rescaled baseline and should therefore still work consistently rather than just overwriting the rescale. (No doubt someone discussed this back on page 5 of this monster thread )

[another_commander]

Ambient lighting counter evidence: Lave


At ambient 0.1




At ambient 0.6:



Yes, it is largely a matter of personal preference too, but in the 0.6 shot there is practically no more dark side left.

[Redspear]

Excellent. Now I have a good means of comparison

0.1 and 0.6 aren't the only values of course...
I'll test some more and include similar shots of Lave next time.

EDIT: As for sun_radius, the 4.25 multiplier is the highest I can go without breaking the 1M limit I think.
Sorry, but I'm thinking that it's not really going to work that way with planets at x6.6 i.e. x4.25 might not be enough.

[Redspear]

Code: Select all

planet_plist_ops = {
        "planet_distance": " * 6.6",       # Planet to Witchpoint
        "sun_distance": " * 1",            # Planet to Sun
        "sun_distance_multiplier": " * 1", # > 1.81 and only if _modifier not set
        "sun_distance_modifier": " * 1",   # <= 1.81. Is this deprecated?
        "radius": " * 1",
        "sun_radius": " * 1",
        "corona_flare": " * 1"
        # TODO: rotation velocities
}

Ok, so there's a few things there but, to use the values I currently have in operation:

PD = * 12
SD = * 6.6
SDM = * 33
R = * 6.6
SR = * 6.6 (not consistently achievable via the plist I believe)
CR = * 6.6
RV = / 6.6

[Redspear]

This is interesting I think.
Similar views to a_c's pictures on my computer...

At 0.1



Note the lack of stars and nebula compared to a_c's images (probably irrelevant besides the reminder that my images are with the rescaling changes and without cosmetic oxps).
Note also that the dark side is all but invisible here and that little white dot over it is effectively masquerading as a star.

On a_c's image you can make out a little of the geography on the dark side but not easily on my image.


At 0.6



A little bright I grant you but nothing like a_c's example I don't think.
Note that my images are (almost) from the same side and rotational period as a_c's examples.


Meanwhile at 0.3...



Just thought I'd test a compromise value while I'm at it. On this (rather limited) evidence, it strikes me as the best of the 3.

[another_commander]

Ah yes, my images were with exposure 1.5. This is why they are not completely identical. The nebulae are due to Zygo's skies, but I had confirmed the ambient levels anyway before posting. But even in your pics, 0.6 ambient looks excessive. For my personal tastes 0.3 is still a bit on the high side, but it is definitely better than 0.6.

[Redspear]

For my personal tastes 0.3 is still a bit on the high side, but it is definitely better than 0.6.

Well, we're agreed there.

That's the problem with ambient light however, the right setting for a planet is likely not the right setting for the ships but ambient lights applies equally.
Speaking of which...


Now that I've got more freedom to scale things independantly of each other (and somewhat surprised by how close that mk3 was on the scanner) I'm going to try the following:

• Scanner x1
• Fighters & multi-role x2 (incl. cargo pods etc but not thargons)
• Freighters and stations x4

Obvious consequences would be greater visibility and easier targeting (even without laser changes). Non player ships are pretty accurate anyway and that in itself is adjustable so it could be fun. That's why we're here in the end I suppose, so it's worth a try.

By the way, almost anyone can test this idea with extensive use of model_scale_factor in a shipdata-overrides.plist, changes to the source are not required. It could be a terrible idea (and likely will be without the odd tweak) but I suspect it might be helpful.