ksp-ro/rosolar

ROSolar

What is it?

ROSolar creates solar panel parts via combining various solar panel models from external mods with rescaling features.

Why is it needed?

ROSolar stems from a combined goal of reducing overall part clutter with the ability to affect solar panel performance when rescale the model.

Many players will typically install mods for specific spacecraft. This can lead to very large installs with parts that are unwanted just to get certain spacecraft. ROSolar, like other RO* Mods (ROCapsules, ROEngines) hopes to address some of those problems by offering a single source for specifically solar panel models.

Who deserves the credit?

All the modders that used their time and considerable skills to develop the models, animations and textures that you see represented in game. Each part that is included inlcudes reference to the original modder that created the part. In all situations I have respected the licenses (as far as I know) and where authors could be reached, I received permission to include them. If you find anything that you do not think should belong, please let me know and I will remove them.

Dependencies

• Module Manager
• ROLibrary

Model Sources Included:

• Bluedog Design by CobaltWolf
• Restock
  • LargeStaticPanel
  • SmallStaticPanel
• SXT
• Ven's
• RN Solar Panels by RaiderNick
  • EOS-AA, EOS-TDRS, EOS-TERRA, NEO-DS, NEAR, Magellan, Dawn, Molniya

Model Sources (External -- ROSolar will configure parts only if the source mod is installed):

• Near Future Solar

Planned Configs/Integration:

• Tantares
• RLA Reborn
• Probes Plus
• Contares
• Lionhead Aerospace

rosolar's Issues

Bad normals on Mariner 8/9 panel

This one

ROSolar/GameData/ROSolar/Data/Models/ModelData-Hinged.cfg

Line 70 in ee300ba

name = CA-Mariner-8

It's not as obvious as on some other parts because it's only a bit reflective, but one can tell the reflections are a bit "off".

Putting the sun right behind it makes it more obvious; it's as if the sun's reflection ends up on the face facing away:

(Mariner 5 also)

Folding panels stay stuck in 'extending' state

(from discord)

A Folding panel that's extended in flight never actually reaches the 'extended' state; it stays stuck in 'extending' even after the animation completes, and never starts producing EC.

Workaround: quicksave, manually change the state to 'extended' in the .sfs, quickload

Appears to affect all variants. Haven't actually tried manually extending a panel; all instances I've noticed were after MJ/PVG auto-extend

Petition to add NearFutureSolar meshes/textures to ROSolar

Pretty self-explanatory.
They look really nice, and there's also quite a bunch of different models to choose from.

There’s some solarpanal in this part can’t tracking, even has “tracking” option.

And some can’t tracking but looks like it can.

After some test, we found:

Have “tracking” option but cant tracking:
Rectangular:
Gigantor

       skylab 

       spacelab 

no “tracking” option but looks like it can:
rectangular:
Copernicus

       nautilus 

 array:
       DRM 

Ranger(sm) panel overstates its area

from discord https://discord.com/channels/319857228905447436/663102368887472156/729339197743169618

ROS-HingedSolarPanel, Trapezoid variant, Ranger(sm) design reports an area that's maybe double what it should be. (Wing design looks more reasonable, have not looked at others)

Ven's variants of Folding panels start out extended

(from discord; logging so it doesn't get forgotten)

Place a panel, leave it collapsed, and switch variants; all the restock variants stay collapsed, but the ven's variants are extended. However the PAW button still says 'extend solar panel', and clicking it performs the animation and leaves the panel extended. So something's inconsistent in the part's internal state.

Worse, if the panel is manually collapsed, then the craft saved (or queued to kct), the next time the same vessel is opened (in VAB or on the pad), the panels will be extended again. (especially a problem on the pad, since there's no 'collapse' button there

Significant offset on attachment

As shown in the screenshots below, there's quite a large gap between where the solar panel is attached and where it initially is placed. As far as I can tell, there is no impact on functionality. Tested with a clean install of 1.8.1 with RO and all dependencies.

Apologies if this is a simple or quick fix I should do myself - I had a look in the config files but didn't see anything unusual.

Static Solar Panel resized to small size results in physics mass different from stated part mass and thus incorrect dV of craft as calculated in MechJeb

A Static Solar Panel resized to 0.14x0.2m, having an area of 0.028 m^2 and using the 11.2kg/m^2 stated for a TL0, should result in a panel mass of 0.3136kg. Checking the .craft file shows that part mass is saved with a couple extra grams at 0.3360kg, a minor difference: (EDIT: TL0 panels are 12kg/m^2, and their mass is thus actually correct at 0.3360kg.)

A test craft with 8 of these panels has the following stats in the hangar:

However, when firing the R103 SRB from a 200x200km orbit, the resulting 200x1572km orbit does not match MechJeb's expended dV value:

This change in apoapsis shows the craft only achieved 359.8 m/s of dV.

Performing the same experiment with a panelless craft of the same mass does result in the expected orbit and dV expenditure.

This leads me to suspect that there is an issue with the part mass of very small solar panels when in a flight scene, leading to incorrect dV of craft. Strangely, the solar panel part mass of the craft in save of a KCT simulation seems to be correct:

Both craft were created in an up-to-date express install of RO and RP-1.
Solar Panel dV tester nopanel.txt
Solar Panel dV tester.txt

Enlarging the panels' size to instead be 0.5x0.2m, results in a 1.2kg panel. However, the orbit achieved after performing the same test burn as before results in an orbit that is no different, even though the craft should have become heavier.

This suggests there's some issue where the panels somehow have a minimum mass in the physics simulation that is not reflected in their actual part configuration data, resulting in miscalculated dV values and thus failed missions.