[1.2] Real Solar System v12.0 Dec 8

[Thesonicgalaxy]

I've never seen that probe, where did you get it?

i built it using stretchy tanks and a AIES Probe and Dish.

[Starwaster]

nathan, fresh KSP (+KJR,KAC,Protractor,MJ,MFS)

fresh RSS, freshly squeezed right out of your dropbox today.

stock solar panels, negative energy. out around Dres.

no atmo editor on leftalt+G

Clarification: stock solar powerCurve IS present and in effect. not deleted.

Edited December 14, 2013 by Starwaster

[Starwaster]

Nathan, looking over the code that handles solar panel fixing, and scrutinizing my logs carefully. Seeing a couple of possible causes here.

Order of operations is as follows

KSP completely compiles parts from configs. Parts already contain stock powerCurve at this point

RSS fixes solar panels in two passes

First it goes through the parts list and adds the RSS powerCurve to module ModuleDeployableSolarPanel for any part that contains that module. (via Load(). AFAIK that only loads a new powerCurve, it doesn't replace the existing one and no code there is removing the old one from the parts. Edit: Should it maybe be sp.powerCurve.Save(curveNode); ???)

Second it goes through the config nodes and removes node powerCurve from 'pNode'. Then adds the rss powerCurve to 'pNode'

Isn't pNode the node containing the PART node and not the MODULE node? Shouldn't that actually be node.RemoveNode() and node.AddNode()?

Also, remember that at this point the stock powerCurve is only being removed from the config nodes. The parts themselves were already compiled and nothing was removed from them.... not that I can see...

                            try
                            {
                                ConfigNode pNode = allParts[j];
                                if (pNode.nodes == null || pNode.nodes.Count <= 0)
                                    continue;
                                for (int i = 0; i < pNode.nodes.Count; i++)
                                {
                                    ConfigNode node = pNode.nodes[i];
                                    if (node.name.Equals("MODULE"))
                                    {
                                        if (node.HasValue("name") && node.GetValue("name").Equals("ModuleDeployableSolarPanel"))
                                        {
                                            pNode.RemoveNode("powerCurve");
                                            pNode.AddNode(curveNode);
                                            print("Fixed part config " + pNode.GetValue("name") + " (" + pNode.GetValue("title") + ")");
                                        }
                                    }
                                }

Edited December 15, 2013 by Starwaster

[SFJackBauer]

I remeber seeing somewhere that, given the latest FAR release that has some configurable parameters in a xml file, that there was some values more appropriate to RSS? Or should I just leave it at the defaults?

[MAKC]

I remeber seeing somewhere that, given the latest FAR release that has some configurable parameters in a xml file, that there was some values more appropriate to RSS? Or should I just leave it at the defaults?

I sent updated config values to MedievalNerd when he asked about including FAR in a pack with RO and all the other RSS thingies, so he has that data as well.

You can figure out the diameter factor, obviously. Incompressible should be set to 0.01, sonic to 0.2.

I think he means attachNodeDiameterFactor should be 1.0.

Edit: Samurai'd by NK.

Edited December 15, 2013 by MAKC

[NathanKell]

Starwaster:

I do:

sp.powerCurve = new FloatCurve();
// commented stuff
sp.powerCurve.Load(curveNode);

If setting it to a new FloatCurve doesn't clear it out, I don't know what does.

You're right about the confignode stuff later, but as you say it shouldn't matter anyway; it's all been loaded.

SFJackBauer: Yes. Set to (in config.xml)

    <string name="attachNodeDiameterFactor">1.0</string>
    <string name="incompressibleRearAttachDrag">0.01</string>
    <string name="sonicRearAdditionalAttachDrag">0.2</string>

Source: http://forum.kerbalspaceprogram.com/threads/20451-0-22-Ferram-Aerospace-Research-v0-11-Aerodynamics-Fixes-For-Planes-Rockets?p=799351&viewfull=1#post799351

EDIT: Ninja'd by MAKC

Edited December 15, 2013 by NathanKell

[Starwaster]

Starwaster:

I do:

sp.powerCurve = new FloatCurve();

// commented stuff

sp.powerCurve.Load(curveNode);[/cpde]

If setting it to a new FloatCurve doesn't clear it out, I don't know what does.

You're right about the confignode stuff later, but as you say it shouldn't matter anyway; it's all been loaded.

EDIT: Ninja'd by MAKC

I just compiled a new version with pNode changed to node.

[s]And that fixed it. Not sure why unless there's more compiling going on later in the log that I didn't see.

Apparently, sp.powerCurve.Load() is the way to go, so what is .Save() for??? Dunno that either.

[/s]

No it doesn't, wth? Just went back out to Pluto and still negative power....

Edit: Ok now this really IS getting bizarre. There are no extraneous stock powerCurve's showing up anymore in the parts database debugger..... and the RSS values are what they should be for solar.

No other weird configs anywhere that might throw things off.

[b]W T H.[/b]

Edit #2: Ok, I'm still sitting in the same game that I've been in since I loaded up with the modified (and, I had hoped, fixed) dll and I went and stuck in my solar panel fixer config and reloaded configs via ModuleManager and the ship out by pluto is getting power now. I really don't get this, those are the same values that RSS is using when it fixes the solar panels and I verified that the stock values are being replaced now but it still doesn't work unless I load up my config file.... And then it works.

Edited December 15, 2013 by Starwaster

[NathanKell]

FloatCurve implements IConfigNode, so that it can be saved to and loaded from confignodes. So when KSP reads a part and sees atmosphereCurve node, it calls this.atmosphereCurve.Load(node.GetNode("atmosphereCurve") or whatever. Same for powerCurve.

Save is needed to save the curve when saving the object that contains it to a confignode (i.e. when going on rails, when saving to .sfs, when saving to .craft, etc.)

My guess is it's maybe a tangent thing. We need to compute tangents for the curve to ensure it never goes below 0.

For now, try adding some more 0-power nodes to the end of the curve in the cfg? Like

key = 5.8741E12 0

key = 5.875E12 0

key = 1.0E13 0

[Starwaster]

FloatCurve implements IConfigNode, so that it can be saved to and loaded from confignodes. So when KSP reads a part and sees atmosphereCurve node, it calls this.atmosphereCurve.Load(node.GetNode("atmosphereCurve") or whatever. Same for powerCurve.

Save is needed to save the curve when saving the object that contains it to a confignode (i.e. when going on rails, when saving to .sfs, when saving to .craft, etc.)

My guess is it's maybe a tangent thing. We need to compute tangents for the curve to ensure it never goes below 0.

For now, try adding some more 0-power nodes to the end of the curve in the cfg? Like

key = 5.8741E12 0

key = 5.875E12 0

key = 1.0E13 0

Actually I was thinking maybe a really small positive value. Something too small to really be useful but big enough that it's non-zero?

Edit: On an unrelated note, all the wonkiness in clicking buildings in the spaceport is totally gone now. In fact, whenever I click something there I get worried that I accidentally ran an install without RSS because it feels like stock now.

Edited December 15, 2013 by Starwaster

[Starwaster]

Ok, I tried your suggestion and it didn't work.

I tried my suggestion and it didn't work.

Getting annoyed now, I will NOT be bested by a bunch of ones and zeroes....

[Starwaster]

Another powerCurve problem. The lines with comments in them (in the powerCurve node) don't get loaded properly into the floatCurve.

That doesn't get rid of the drain problem at extreme range. Seems to happen sometime around Jool's orbit...

So, fixed the problem with the nodes so that the powerCurve is actually put inside the solar panel, checked that the only powerCurve in there is the one we want, removed comments so all of the node is being properly loaded and also tried adding additional lines to clamp the end of the curve.

Tried this too:

(put a really large number for the final range and a really small number to stretch the curve out)

		key = 0E0 223.8
		key = 5.79091E10 6.6736
		key = 1.08208E11 1.9113
		key = 1.49598261E11 1.0
		key = 2.279391E11 0.431
		key = 7.785472E11 0.037
		key = 5.874E12 0.0001E0
		key = 3.40282E37 0.000000000001E0

[Guest]

This is great stuff. I just got the second iteration of 6.4:1 Kerbin up and running. Took roughly 7km/s to get to orbit with FAR, everything feels right so far (although the 2.2km/s to get to the Mun is a bit scary, lol). Again, thanks for all the hard work!

[jrandom]

This is great stuff. I just got the second iteration of 6.4:1 Kerbin up and running. Took roughly 7km/s to get to orbit with FAR, everything feels right so far (although the 2.2km/s to get to the Mun is a bit scary, lol). Again, thanks for all the hard work!

6.4:1? I've got 1:1 over here (according to the info panel in map view re: RSSKerbin's radius)... is that a different configuration for RSS?

[NathanKell]

regex! Cool! Glad it's leading to more use than just this. Amazing what open source modular code allows...

jrandom: regex has been making a 6.4x scaleup of the Kerbol system.

[Guest]

6.4:1? I've got 1:1 over here (according to the info panel in map view re: RSSKerbin's radius)... is that a different configuration for RSS?

It's a config I'm working on that focuses purely on resizing the Kerbin system rather than rearranging it and going for analogues. I used 6.4:1 because I recall reading somewhere that all of the ship models were 64% of actual size. It's also something no one else seems to be doing, so I figured I could fill a niche. Technically the base RSS config is about 10:1 Kerbin, so this ends up being smaller overall (the orbital velocity should confirm that).

[Starwaster]

To those having solar panel issues:

(Nathan, hope you don't mind this hot fix... I think you won't)

Replace your RealSolarSystemSettings.cfg with this file:

https://www.dropbox.com/s/hmv5f7y7hyv7i2o/RealSolarSystemSettings.cfg

You probably also need to replace the dll:

https://www.dropbox.com/s/3r0lcls0s4k0n3c/RealSolarSystem.dll

(source)

https://www.dropbox.com/s/n35w7sn81qua7f3/RealSolarSystem.cs

If you still have my old solar panel fixer cfg, that by itself probably still works too.

[SFJackBauer]

Thanks, I will try it when you can post the file. (Please include all of the parts that are resized as-well, as I don't have B9)

Just a bit of an update on the shuttle - I'm having some problems figuring out why in the hypersonic to supersonic transition it goes haywire. All other phases of flight are OK, but when adjusting the aerodynamics for reentry I have to test the ascent again to be sure its not messed up, so it takes a bit of time to perfect it.

And I took a second pass on dimensions and masses, it is now done, here is a pic of me with the measuring tapes

[Starwaster]

Just a bit of an update on the shuttle - I'm having some problems figuring out why in the hypersonic to supersonic transition it goes haywire. All other phases of flight are OK, but when adjusting the aerodynamics for reentry I have to test the ascent again to be sure its not messed up, so it takes a bit of time to perfect it.

And I took a second pass on dimensions and masses, it is now done, here is a pic of me with the measuring tapes

Maybe throttle down to ease into it?

In the case of the real shuttle they did have to throttle back at several points in its ascent....

[SFJackBauer]

Maybe throttle down to ease into it?

In the case of the real shuttle they did have to throttle back at several points in its ascent....

No old man, the solar panels woes are interfering with your congition. Its from hypersonic to supersonic, its during reentry Between Mach 8 to 7 it acted out, but I found the culprit - I had set the rudder to roll, not yaw. (perhaps I am the old man?)

EDIT - IT HAS LANDED! Not an impressive landing, but lets put that on the bad piloting.

I circled around after the reentry and went too hot... over-reacted and overshot the runway. Need to come in shallower and flare earlier.

I have to say my heart was pounding after it, after all the re-entry is a half-hour thrill ride that is so easy to get wrong... I still get amazed by how this 70 ton glider managed to be built and flown.

Edited December 15, 2013 by SFJackBauer

[Starwaster]

No old man, the solar panels woes are interfering with your congition.

Clearly you have divined the truth... And suddenly I want segue into Dennis scene from Monty Python and the Holy Grail

[Deathsoul097]

Wasn't the Shuttle only 50 Tonnes?

EDIT: *Looks at Wiki page* I stand corrected. Endeavour was 78 tonnes.

EDIT EDIT: You might want to look at the Space shuttle engines and systems by dtobi, they help significantly with creating working space shuttles, and if you resize the OMS pods, and make them carry the correct amount of MMH/N2O4, you could have an almost exact STS replica.

Edited December 16, 2013 by Deathsoul097

[AbeS]

It is 50t in his video

[SFJackBauer]

You see, that's why we shouldn't thrust Wikipedia. The info on the amount of OMS propellant is not easy to come by. Yesterday I was doing some calculations based on the Wiki entry on OMS. It says "the pods together carried around 8,174 kilograms (18,021 lb) of MMH and 13,486 kilograms (29,732 lb) of N2O4, allowing the OMS to produce a total of around 1,000 feet per second (300 m/s) of delta-v". But if we plug this numbers into the rocket equation (109t vehicle expending 21.5t of propellant at 315 Isp) it gives two times the delta-V (679 m/s to be precise).

But the Wiki article is corroborated by a NASA page (well, its an "Ask the Astrophysicist page"...), which says each pod carried 10,830kg. So if I assume this is correct, then:

- The max liftoff mass is 109t (several sources agree on this)

- The max payload is ~30t, leaving an orbiter of 79t

- Subtracting the OMS propellant (21.5t) and RCS propellant (~2t) it arrives at a 55.5t dry weight.

Now a lot of places says the orbiter dry weight was 79t, which must include the OMS propellants. However two places I found specify that the OMS propellant is, in fact, half of the above: Braeunig and a NASA document I could only access through Google cached. In fact, this last document that I found today is quite explicit and technical in the numbers and explanation, which lead me to believe it is the closest to the truth. So basing on it, the OMS and RCS propellant mass would be:

OMS - 11.3t

RCS - 3.5t

Total - 14.7t

Thus the orbiter true dry weight would be 79 - 14.7 = 64.3t. And the rocket equation for a fully-loaded shuttle with those numbers gives 338 m/s dV. So off I go to fix the masses again

(P.S. If you guys could see the amount of opened tabs my browser Chrome has... a few more and even the icons will not be visible anymore...)

Edited December 16, 2013 by SFJackBauer

[Starwaster]

(P.S. If you guys could see the amount of opened tabs my browser Chrome has... a few more and even the icons will not be visible anymore...)

Wow, glad to see I'm not the only one. At the height of my NTR research you could barely tell they WERE tabs. And because I would automatically download anything that looked like a pdf / ppt my downloads folder is littered with duplicates. I have a ton of documents by Stan Borowski on NTRs and Copernicus.

I just wish to god they would stop mixing metric and imperial. It's embarrassing, no wonder we lost that Mars probe.

[NathanKell]

Yep, tab-opolis here too.

Starwaster: The only change I see in that source file you posted is the reversion of the typos you yourself found (I should be changing node, not pNode). Did you mean to change anything in the source?