[1.2] Real Solar System v12.0 Dec 8

[Sternface]

So for some reason my little .cfg edit fix with the solar panels only worked on the Squad static solar panel (I believe it is #5, the non-tracking one).

I launched a probe to intercept Jool with the Squad sun-tracking 6x1 panel, and it stopped producing energy about half way to Jool.

I have tried the following with no success:

*Installed ModuleManager 1.5, and created a .cfg as per Starwaster's suggestion. (The RSS.Solar.Fixer.cfg)

*Reverted the RSS .cfg file to stock, without Starwaster's fix.

*Reverted the RSS .cfg file to stock, and included Starwaster's fix.

*Installed NKReal tweaks, without Starwaster's fix.

*Installed NKReal tweaks, and included Starwaster's fix.

Not only did the panels not work half-way to Jool, but they didn't work at all in LEO. Zero energy production despite having 100% access to sunlight.

Then I installed the batteries and solar panels from AIES, which I had previously left out.

*Built a test satellite which included one of each variant of the Squad and AIES solar panels, and inserted into LEO. Interestingly, none of the 5 squad panels worked at all. Not one drop of energy production. However, a few (but not all) of the AIES panels worked. The energy production seemed pretty meager, but I am not sure if this is intended as a design choice, considering that I noticed the massive increase in battery capacity.

I had both the NKReal tweaks and Starwaster's fix installed for this test satellite.

Any suggestions? I feel like I am missing the obvious.

When I implemented the fix, I put the ModuleManager1.5 into the Gamedata folder, and used Notepad++ to create the text document. I wasn't sure if I needed to save it as a specific type of file, or if I needed to include the .cfg extension, so I just opened an existing .cfg file, cleared the contents, copied the fix in, and saved it as 'RSS.Solar.Fixer'. I tried putting the RSS.Solar.Fixer.cfg in both the RSS folder, as well as the Gamedata folder.

P.S. I recently installed KSP interstellar, which is the only other mod I can see having an effect, as it added the waste-heat resource to all solar panels. But I looked through the files and I couldn't see anything apparent that would have affected the power curve.

Edited November 18, 2013 by Sternface

[sephirotic]

Sorry if this has already been asked but i had no luck with the search for this thread.

So, I was converting Vall to Encenladus, since Pluto is not even a planet and is so far away that it felt pointless to me to have it there.

Then i saw that Laythe's atmosphere data in the cfg hasn´t be changed, neither it's gravity to match titan's. Is this setting anywhere else or is it still less than 1 ATM and 0.8g?

How would i configure it's atmosphere to mimic titan's? Why not add it in the config?

And the second thing is:

While I was configuring Enceladus data i came across this values:

LAN

meanAnomaly

and argument of Periapsis

How do i configure these?

I'm obviously using wikipedia's data. Tough i believe there should be websites with more complete data, like nasa's

Thanks a lot.

Edited November 18, 2013 by sephirotic

[Starwaster]

And what exactly are you modding there?

Me? It tweaks some resource masses to more accuracy. I think Nathan is doing the same soon so that will be obsolete. It also adds Kethane as a usable propellant in stock and KW engines and adds kethane, ammonia and water as nuclear propellants. Getting a craft with a decently sized tank of ammonia was a herculean task in stock. Water even more so. Sending the craft up empty followed by just the tank was easier. And finally, Kethane Converter got a patch to allow it to produce ammonia.

So for some reason my little .cfg edit fix with the solar panels only worked on the Squad static solar panel (I believe it is #5, the non-tracking one).

I launched a probe to intercept Jool with the Squad sun-tracking 6x1 panel, and it stopped producing energy about half way to Jool.

I have tried the following with no success:

*Installed ModuleManager 1.5, and created a .cfg as per Starwaster's suggestion. (The RSS.Solar.Fixer.cfg)

*Reverted the RSS .cfg file to stock, without Starwaster's fix.

*Reverted the RSS .cfg file to stock, and included Starwaster's fix.

*Installed NKReal tweaks, without Starwaster's fix.

*Installed NKReal tweaks, and included Starwaster's fix.

Not only did the panels not work half-way to Jool, but they didn't work at all in LEO. Zero energy production despite having 100% access to sunlight.

Then I installed the batteries and solar panels from AIES, which I had previously left out.

Any suggestions? I feel like I am missing the obvious.

When I implemented the fix, I put the ModuleManager1.5 into the Gamedata folder, and used Notepad++ to create the text document. I wasn't sure if I needed to save it as a specific type of file, or if I needed to include the .cfg extension, so I just opened an existing .cfg file, cleared the contents, copied the fix in, and saved it as 'RSS.Solar.Fixer'. I tried putting the RSS.Solar.Fixer.cfg in both the RSS folder, as well as the Gamedata folder.

P.S. I recently installed KSP interstellar, which is the only other mod I can see having an effect, as it added the waste-heat resource to all solar panels. But I looked through the files and I couldn't see anything apparent that would have affected the power curve.

Make sure KSPI didn't stick an older version of ModuleManager in there. Get rid of it and just use 1.5, I think thats stable enough.

[Sternface]

Make sure KSPI didn't stick an older version of ModuleManager in there. Get rid of it and just use 1.5, I think thats stable enough.

Yep, no go. I actually really like the design choice behind the lower energy production + higher batter capacity in NKReal, so I'll just use the AIES panels which appear to be working properly. I took a closer look at it and it does appear to be a design choice.

On a positive note, I learned how to write a patch for modulemanager trying to find the problem I was having with your fix That will save me a lot of time in the future.

EDIT:

So it appears that KSPI also implements an inverse-square dependency on all the stock panels except for one - the one that worked for me. I'll post a solution for anyone else having trouble when I find it.

Edited November 19, 2013 by Sternface

[NathanKell]

diablos: when I get a sec I'll use asmi's ECLSS framework to add orbital decay.

Regarding solar panels: I'm testing a new fix that's a real "belt and suspenders approach":

*Fix all existing SP Modules

*Fix all SP module snapshots in unloaded vessels

*Fix all powerCurves in solar panel confignodes (what the MM fix does).

We'll see if that does for everything.

Starwaster: what resources masses aren't accurate in the latest MFSC?

I'd be happy to merge your changes into the latest MFSC if you're willing.

sephirotic: That's weird. Coulda sworn I did set up Titanilaythe's atmosphere, but apparently not. Fixed for next. Note that you only need to specify *either* a body's mass or its surface gravity; RSS will calculate the other, based on radius.

Regarding LAN, meanAnomaly, and AoP: I was unable to find reference data for those, so I didn't configure them for moons; that seems to be because moons' orbits are perturbed sufficiently rapidly by their parent bodies that those values change over time. If you can find that data for moons (I'm using the J2000 epoch BTW) then you can configure them just like the planets' are: by adding the appropriate keys to the Orbit {} block.

[Starwaster]

Yep, no go. I actually really like the design choice behind the lower energy production + higher batter capacity in NKReal, so I'll just use the AIES panels which appear to be working properly. I took a closer look at it and it does appear to be a design choice.

On a positive note, I learned how to write a patch for modulemanager trying to find the problem I was having with your fix That will save me a lot of time in the future.

EDIT:

So it appears that KSPI also implements an inverse-square dependency on all the stock panels except for one - the one that worked for me. I'll post a solution for anyone else having trouble when I find it.

One possibility is that the RSS power curve node is still in the realsolarsystemsettings.cfg file and interfering somehow. When I was working on the fix, I had totally commented that section out. But the fix worked for Istas (and others I hope) and I had not told him to clear that out.

So. Suggestion: comment out the powercurve data in RealSolarSystemSettings.cfg and see if my fix works then. If you still have troubles use the debug menu and check the part. Check for duplicate powerCurve blocks.

diablos: when I get a sec I'll use asmi's ECLSS framework to add orbital decay.

Regarding solar panels: I'm testing a new fix that's a real "belt and suspenders approach":

*Fix all existing SP Modules

*Fix all SP module snapshots in unloaded vessels

*Fix all powerCurves in solar panel confignodes (what the MM fix does).

We'll see if that does for everything.

Starwaster: what resources masses aren't accurate in the latest MFSC?

I'd be happy to merge your changes into the latest MFSC if you're willing

Any resources with rounded mass figures

though I hadnt looked at them in the latest release so for all I know you corrected them... I think you were talking along those lines previously?

I think the new SWMFSC file in my sig has correct ones. But I've clearly grown sloppy in the past couple of weeks Or I would not be using modified resource masses without first seeing if you had changed them. so I guess I better go do that now before I play one more second.

Edit: yup, they're rounded. I have OCD when it comes to rounded numbers. Also un-indented code

Edited November 19, 2013 by Starwaster

[metaphor]

Since you're using the J2000 epoch, does that mean that on Year 1 Day 1 in KSP, the planets are in the same alignment as on January 1, 2000 in reality?

[Starwaster]

Since you're using the J2000 epoch, does that mean that on Year 1 Day 1 in KSP, the planets are in the same alignment as on January 1, 2000 in reality?

yeah good question, how do we check that??? and we go back even further and duplicate the real Grand Tour????

[dlrk]

Can I get some advice on ascent profile? I've got fins on the bottom, but my rockets, tend to either become unstable in pitch, or abruptly swing back and explode due to over g.

[Starwaster]

Can I get some advice on ascent profile? I've got fins on the bottom, but my rockets, tend to either become unstable in pitch, or abruptly swing back and explode due to over g.

Sounds like you did too drastic of a gravity turn too soon. Start early but not too much.

And maybe too fast at the wrong time. I always question that advice when I see it. Real rockets go supersonic fairly early in their flights dont they?

And the shuttle went over mach 1 about a minute and a half into its flight. whatever though... you're using FAR obviously so configure it to report mach numbers and try to keep it below 1.2 until maybe 20Km up?

and if you have multiple engines, gimbal lock the middle one. If you do try that though and you jettison the outer engines do not forget to free the middle one especially if you are too high for fins

[NathanKell]

1. Yes, the planets are in the alignment of Jan 1 2000 on KSP start. I plan to change everything's time-since-epoch to 1950, so you can time-accel and to a grand tour.

2. I'll use your mass figures. I undid the rounding in excel, but it's only as accurate as the info I got (wiki mostly for density, and they use 4 sig figs).

All my autogenerated code has spaces instead of tabs (because excel doesn't export tabs), but is indented (I hates it too); for the rest, take it up with Chestburster.

[NathanKell]

Doesn't matter how fast you go. Matters that you start turning at about 100m/s and keep your nose only a few degrees off surface prograde at the most.

EDIT: For MJ ascents. Set turn start to the altitude at which your rocket reaches 100m/s. Set turn end to somwhere between 80 and 180, and turn shape 60-80 or so, depending on TWR later in flight.

[dlrk]

I'll try limiting the Mac as you suggest. What altitude/speed do you recommend for gravity turn?

[ferram4]

No, staying in the transonic regime for that long (which is what he'd being doing to keep the Mach number low enough) is the exact worst thing to do. That's where rockets and planes are least stable.

@dlrk: The first thing to keep in mind is that a high TWR is a really bad idea; ~1.4 is good, you can go down to 1.2 if you want. The second thing is that you probably don't have enough fins or your rocket doesn't flare out enough near the bottom; this is especially true if you're running a kerolox lower stage with a hydrolox upper stage, in which case you need a lot of fins to stabilize the thing. Make sure to throttle down around Mach 0.7 and keep your throttle near ~75% until the rocket becomes easier to control; this will lessen the aerodynamic forces. Pictures of what you're trying to launch are generally helpful, since we don't know whether your launch vehicles are close to good but with some flaws or if they're completely wrong.

Pitch over very slowly at 60 m/s for a TWR of ~1.4-1.5. Wait until ~100 m/s for 1.2. Altitude is whenever you hit that speed.

[dlrk]

Okay, I'll try throttling back at .7, and starting the gravity turn later.

I'm launching this: http://i.imgur.com/8IY6pNN.png

Anecdotal evidence/looking at FAR data suggests that it's related to Q.

[NathanKell]

No, it's not. DO NOT throttle back. As ferram said, that's the worst thing you can do. Keep your vessel's forward-marker near the surface-prograde marker at all times (don't turn too fast). With the FAR details panel open, make sure AoA and Sideslip is no more than 5 (or less than -5) at any time.

Sorry. Misread, thought you meant throttle back to 70%. Yes, follow ferram's advice.

Edited November 19, 2013 by NathanKell

[ferram4]

@dlrk: That rocket looks like it has a very high TWR; you could probably get away with the Titan instead of the Griffon and that would solve your issues. The way that you've attached the B9 RCS tanks will probably add quite a bit of drag, and you don't need the SPS engine for that tiny orbiter; I'd actually say that a good fix would be to replace the SPS with the LV-909, put the RCS tanks under the fuel tank and use a procedural fairings interstage to shield the 909 and the RCS tanks. That should help make the upper bit of the rocket smoother and less draggy, since there's no way you should need that much fin for that rocket.

@NathanKell: You can throttle back a little bit, but hovering in the transonic regime too much is a problem. Throttling back to decrease Max Q slightly makes sense, but only if you can still maintain a TWR of ~1.6 through the entire regime.

[NathanKell]

Right, I misread, and edited my post to that effect.

[dlrk]

I'll try redesigning the Orbiter as you suggest, and use a less powerful first stage engine. It does a have a high TWR.

Are there tri/bi/quad couplers available for 3.25m tanks?

[ferram4]

I think NovaPunch has 3.75m to excessive number of 1.25m adapters. I gather you're looking to slap multiple 2.5m engines on the bottom instead? The best option I've found is to use the KW Rocketry fuel adapters to slim it down to a 2.5m engine and then add boosters to bring the TWR up (if necessary).

[dlrk]

Got it, thanks. Looks like lowering the TWR definitely helped, although the Titan delivers 1.07 TWR at launch, so something in between the two would be better.

Can you advise on the profile a bit more? I'm having some difficulty figuring out how to circularize without excessively raising the apoapsis, it looks like it requires a very different technique than stock.

[iVG]

It's amazingly different from stock. Once you get it though you'll be like 'meh' at real life launches

[NathanKell]

Just use radial attachment points or cubic struts.

[dlrk]

I still can't figure out what keeps going wrong. I'll be just past Max Q(q decreasing on FAR panel), around 10,500m, TWR of 1.6-1.8, and, the rocket will start to pitch up, and violent eject the capsule.

[ferram4]

Then taking the Titan is a good idea; slap on a pair of long burn SRBs and it'll lift off quite nicely.

The first thing to keep in mind is what altitude you're looking for; if you want realistic orbits, you're shooting for 200km-300km orbits. I've generally found that for two-stage rockets, having the velocity vector at ~35-40 degrees above the horizon at ~1500 m/s is generally good (this is due to two-stage rockets generally having higher peak accelerations than three-stage rockets, which means a flatter ascent profile with the two-stage). The thing to keep in mind is you're looking at going for ~7.7km/s of horizontal velocity in orbit, so most of your burning must be done horizontally. If your TWR is high enough at a certain point it just makes sense to burn purely horizontally, but this can kill you if your orbiter needs to circularize and it happens to be underpowered.

A lot of it becomes very rocket-specific, so I'd need to know initial and burnout TWR for each stage as well as the burnout velocity for each to give you more advice.

Are you using Kerbal Joint Reinforcement? If you aren't the higher masses needed might be causing you issues.