Spacecat2000

Great job on this mod, I love it. And I have a little proposal if you want to save a bit of space: you could entirely eliminate the two 'time steps' in seconds if you combine with m/s, and maybe move the 'time' thing higher than the 'snap to' commands. It makes sense visually that way... Trust us to know the small step and large step are m/s or seconds. Here's a mockup of what I'm suggesting:

Ah, I see a small update to indicate KESA solar works with the current version, good! So JiMKesa, are you going to tweak small issues on the panels, or are you working on other things? (You've been awfully silent)

Ohhh, it can't be defined for small bodies only, gotcha! I thought the FOV was more case-specific, my bad. And thanks for the update! Auto opening the body is a nice quality of life improvement.

Duly noted why the altitude has to remain high around Gilly, I accept that. It's still pesky how easily a satellite scanned the surface image, but how it takes forever to get the regions since its altitude can't be ideal at all around Gilly... I'm not looking forward to Bop and Pol. So, apologies if I'm not letting go of that bone too easily but... Proposal to improve quality of life around those smallest moons: Any chance the angle of region scanning could be a half or a full degree broader for small bodies? Orrr maybe reduce the penalty (only for small bodies, not for all) if one is below ideal altitude? - Just a compensation for the slower orbital speeds around those. What do you think Falki?

Great job falki, love the new waypoint functionality. Though I have a little something on my wishlist: I currently have a surveyor sat in orbit around Gilly, and the ideal altitude is so high compared to Gilly's limit that the sat is actually 'below ideal' altitude still... And with the measly orbital speed around Gilly (especially so close to its SOI limit), even a single orbit takes ages. 2 months later, I still haven't hit 25% covering for the region. Sooo, the wish: Any chance you could notably reduce the ideal altitude for small bodies as you tweak the altitudes anew? Perhaps improve the angle for region mapping (small bodies) just a notch? That poor Gillysat would thank you dearly.

Hey Jim, You might want to do an update to indicate your mod works in the latest version of KSP2, because it does.

Bravo Falki! At last varied altitudes! rogerawong that's as intended by Falki. Only vessels with orbital-survey-capable antennae will appear on the survey screen.

Glad one of my ideas (scaling variable) will be helpful. 'Realistic' is arguable as orbital scanners rely more on resolution than aperture (I think), buuut I totally getcha about it being 'fun' to have variance for bigger/smaller worlds! By all means, let's stick to that method, haha. So hopefully lower altitudes will do the trick, I gave you the crazy chart. Bonus points if this new altitude is for 'sub-100 km radius bodies' as that's easy to remember. And if you find a 'big worlds' setting that works for both Jool and Kerbol, you'll have your big bodies all set too! Hahaha. 'fraid I can't help with testing those altitudes by tweaking the mod, so i'll just wish you well.

Hey Falki, I just had a crazy idea... Right now you want to make it so the survey doesn't scan too wide when they're at optimal altitude... It's tricky because the scanner has a fixed aperture angle. What if it wasn't a fixed angle? Let's say someone comes up with the math formula that takes the stellar body's radius, and gives the needed aperture for '7 map pixels wide being scanned', and then the orbital scanner adjusts its aperture to match (like a zoom on a camera), depending what body it's orbiting. If the sat is at ideal altitude, set to correct angle, if it's less or more, mess with the aperture to get less pixels wide. Then you could have your ideal altitudes be according to the simple table, and our rugged orbital scanner would adjust as necessary.

Agreed, we could rephrase goal 1 to 'Make sense with the body size, and keep system performance in mind'... RSS has a completely different scale than stock... So here's a random idea for forward-compatibility: We're not sure what future solar systems will be like, but if you balance thing well for the Kerbolar system, there's a high likelyhood it'll work for future systems to the same scale. Let's say you balance everything for 'stock size' but keep a sort of... multiplier in your code that in the future will be easy to adjust if someone plays the game with non-stock scale. Say 2.5X scale, or the 10x scale for the solar system... Think that'd work?

Falki, amazing work! And you demonstrated with style and cool music to boot! It is my wish to help you hash out a solution to varying the effective height so one isn't too high on Gilly or too low on Jool, say... So let's summarize the design goals: 1-Make sense with the body size (high altitude on gas giants, low altitude on small moons, doesn't need to be precise, just roughly sensical) 2-Don't be so low we hit an atmosphere 3-Don't be so high we hit a SOI (like Gilly's) or a lower moon. (Jool vs Laythe, Duna vs Ike) 4-Make it forward-compatible with any future solar systems, such as planet packs or wherever we'll meet our alien cousins. 5-Give a hint to the proper altitude in the part specs, so we can plan interplanetary probes. Using pure math would result in weird numbers, would likely solve 1-4, 5 would be messed up. I had once suggested 'maybe classify worlds in 'Small bodies' 'Mid-sized bodies' 'Big ones' and give the values for all three in the parts, that would help with #5, but makes things tricky with #4 as you can't just make a list of Kerbol's worlds and put them in a table. ...Or can we? How about we look at a table with kerbol's bodiess, in order of body width, showing low moon's altitude/SOI limit, and atmospheric depth for the hell of it. I'm hoping this chart can help you figure out some good limiters for 'Small body' 'Mid Body' and 'Big ones'. Then we can pray those limiters would work with any future solar system. Body name Equatorial radius (m) Atmosphere depth (m) Maximum safe altitude (m) SOI limit or nearest moon's SOI SOI limit Nearest moon Pe minus moon SOI Radius (approx) Gilly 13 000 0 126 123 126 123 Pol 44 000 0 1 042 138 1 042 138 Minmus 60 000 0 2 247 428 2 247 428 Bop 65 000 0 1 221 060 1 221 060 Ike 130 000 0 1 049 598 1 049 598 Dres 138 000 0 32 832 840 32 832 840 Mun 200 000 0 2 429 559 2 429 559 Eeloo 210 000 0 119 082 941 119 082 941 Moho 250 000 0 9 646 663 9 646 663 Vall 300 000 0 2 406 400 2 406 400 Duna 320 000 50 000 2 000 000 Ike: 2 000 000 Laythe 500 000 50 000 3 723 645 3 723 645 Kerbin 600 000 70 000 9 500 000 Mun: 9 500 000 Tylo 600 000 0 10 856 518 10 856 518 Eve 700 000 90 000 14 000 000 Gilly: 14 000 000 Jool 6 000 000 200 000 23 000 000 Laythe: 23 000 000 Kerbol 261 600 000 600 000 4.2 Gigameters Moho: 4.2 Gm Looking at this, Gilly's a clear outlier, Duna and Jool are touchy, every other SOI is all over the place but easy to work with. Maybe you can get away with something like 'Small bodies - below 100 km radius' (Gilly, POl, Minmus, Bop) Maybe orbital survey 20km - 40km - 80 max? 'Medium bodies - 100 to 1000 km radius' (Ike to Eve) Current Orbital survey heights we know work well. 'Large bodies - above 1000 km radius' (Jool and Kerbol) Orbital survey needs testing... Anyway, hope that little chart helps you out. (I got the values from KSP1's wiki)

Thank you JiMKesa! The small not-working panel is now fixed, and things are much, much better balanced! Hope you won't mind if I make another pass to spot oddities and outliers. At this point it's almost nitpicking, so feel free to ignore me. Hahaha! Again, just hoping to make your mod even better with a balancing pass... "In the XS and Small panels category, our outliers are..." -I made a visual check of all small panels, only the DSPF-L2 struck me as odd: Visually it's barely bigger than a STAT-XL (1.25 EC/s) and clearly smaller than the twice-its-weight S1 (4 EC/s) yet still puts out 4EC/s. I think it'd make more sense at around half that as it's half the weight of its big brother and visually half as small give or take... -The CSP-XS1 has 0.3 EC battery... I blinked a few times, that should be 3EC, right? "In the medium category..." Visual check, the DSPC-M1 and DSSPC-M1 struck me as quite large-looking for a 2EC/S panel, I see you gave it twice the weight and twice the EC/s of its small cousin, but visually it's more like four times the area and... about as impressive as the CSP-G25 (4.5 EC/s) My humble opinion is you could make that pair 3.5 or 4 EC/s, with about twice its current weight and it'd make more sense. (Some folks would say the Hubble is higher performance per weight than the Gigantor, I don't mind, I'm not -that- nitpicky.) Smashing job overall, I can't find fault with anything else! "In the large and XL category..." I ended up comparing G25, G5 and G375 and oops, the three have about the same weight and EC/s when the G5 is about twice the visible area of the G25. Since they're flush panels with no mechanisms nor batteries, I think you can get away with making the G25 noticably lighter (how about 3-4 times the STAT-XL, so 20-25 kg?) Then from there, make the G5 twice the weight and EC/s, and the G375 1.5 times... Roughly those values would make visual sense i believe. All other panels have weights and EC values that are roughly balanced with the game's offers, yet give us a visual treat and variety. I have to say again: Excellent work and thank you immensely!

For a moment I was telling myself, "Hmm, that would make the desired height a bit unpredictable at launch time, perhaps a 'normal altitude for small bodies', 'normal altitude for mid-sized bodies' and a 'normal altitude for giants' would be more intuitive. But then I realized that if you go by body size, that would make your mod more compatible with future planet packs (or those extra solar systems the devs are working on). So by all means! Your idea to use a dynamic calculation with body width is superb! But I just thought of two things to keep in mind: 1- It's annoying if the right altitude ends up intersecting with a moon. But I trust you'll find a sweet spot between the atmosphere and nearby moons/inside the SOI for virtually all cases. 2-It's good if we have a fair idea what altitude to aim for before we launch a scansat to an interplanetary target. So maybe a little in-game text to give us some rough values ahead of time would be neat... (Oh, you might want to round that dynamic altitude to the nearest ten, to avoid 'oddly specific' values, haha) And I must express my sincerest compliments on this mod. I'm also a big, big fan of Scansat. Cheers!

Thank you very much for a lovely parts mod! My first and favorite so far, kudos! Sorry for this constructive criticism, I just hope to help you make this even greater. Probable bug: The FSP-XS1 doesn't seem to work for me, it doesn't seem to detect stellar exposure and gives no power (the 500 ec battery does work though) The DSP-Hubble clocks in at 350 Kgs! Much heavier than similarily sized panels. May I recommend a 'fair weight' of around 3/4 the Gigantor 's? 120 kgs or less maybe (and why is the in-game SAW1 so light? hmmm) The DSPF-J1 feels off. It's visually gigantic, but doesn't give much power (barely more than M25) and is very lightweight. I would propose to make it go sort of between the Gigantor and SAW1 in energy produced? (somewhere between 12 and 55 ec/s) Balance recommendations: Having a bit of EC along with solar panels is nice, but 500 ec for a 3kg panel feels quite unbalanced compared to the game. Might I suggest keeping those batteries small (20-50 EC for small panels 100-200 for large panels maybe?) just keeping in mind in-game batteries weigh about 1kg for 20 EC.