undercoveryankee

I've added https://github.com/FractalUK/KSPInterstellar/wiki/Solar-power-satellites to the wiki to collect everything we know about beamed solar power after the latest discussion. I wrote down what I currently know, but there are probably a few things left to add.

Try simplifying the rocket. Remove the reactor and generators entirely - a fission reactor doesn't supply enough power to lift its own weight with a plasma thruster, so you're only hurting yourself by having it on board. Remove the lithium, reduce the monopropellant to what you're going to need for RCS, and right-click the thruster and make sure it's running on argon or xenon. Right-click each umbrella receiver to see how much power it's receiving. On the launch pad, make sure you have a receiver pointed directly at each of your ground stations. Atmosphere eats power, so most of what you have on the ground will come from the ground stations. It helps to put the receivers on Infernal Robotics hinges so you can fine-tune their angle without rotating the entire ship. It sounds like you have a total of four Akula reactors across all of your ground stations. Upgraded, each of those has a maximum of 7.5 GW thermal power. Taking into account reactor power decreasing with core temperature, generator losses, and atmospheric transmission losses, you should be able to receive maybe 3 GW if you aim your receivers right, which should get you 176 kN on argon. Or about a third of that if the reactors aren't upgraded.

Edit: This was a repeat of the previous post because it looked like it had failed to post. I'll use it to continue the discussion. With regard to battery requirements: the FixedUpdate tick that governs power consumption is 0.02 s. Rabada has 24,000 EC capacity. 24,000 divided by 0.02 s equals 1,200,000 per second, which is the observed 1.2 GW. Let me see if I can work out the math for this configuration. You said the satellite has 12 single Balkas. I don't have that .cfg, but I'm guessing (based on http://forum.kerbalspaceprogram.com/threads/43839-0-23-5-KSP-Interstellar-%28Toolbar-Integration-New-Models-New-Tech%29-Version-0-11?p=1171247&viewfull=1#post1171247 where you quoted part of the double Balka's config) that the single has a chargeRate of 200. 200 * 12 = 2,400 kW at Kerbin. Scale to 100 km altitude. That's small enough compared to the sun's radius that the multiplier will still round to 2,700. 2,400 kW * 2,700 = 6,480,000 KW = 6.48 GW. Divide the power in kW by 50 to get the amount of EC in 0.02 s. I get 129,600 EC required to transmit the full panel capacity.

The only limit in the code is how close you can get to the sun before bad things start happening to your ship. The sun's radius is 261,600 km, and Kerbin's semimajor axis is 13,591,840 km. If you square that ratio, the largest boost you'll see before hitting the sun is a little under 2,700 times the panel's output at Kerbin. In RL, the fact that the sun is not a point source would cause the inverse-square law to start breaking down quite a bit farther out, not to mention that the panels themselves have a maximum amount of light they can process. Trying to model these corrections would cost software performance everywhere for effects that most vessels will never encounter, so the code uses unmodified inverse-square.

The radiator temperature that you experience is completely determined by the amount of waste heat in the radiators, and the only waste heat source that varies with location that I can find is solar panels. So if you're not using solar panels, you just work out the equilibrium heat production, temperature, and area according to the wiki and it will work anywhere. If you're using solar panels, you'll need to figure the panels' power output at your target orbit, and their heat output will be half of their electrical output. Since Interstellar dynamically modifies the curve from what's in the .cfg file to a more realistic inverse-square curve, predicting solar panels is not yet well-documented. Edit: After another look at the source code, I think I've got my head around what Interstellar does to solar panels. The chargeRate in the .cfg file gives the available power (in EC/s = KW) for 100% sun exposure at Kerbin's distance from the sun. The powerCurve in the .cfg file is completely replaced. On each FixedUpdate (every 0.02 s), the plugin calculates the ratio between the panel's distance from the sun and Kerbin's distance from the sun and applies a single-point curve that multiplies the panel's output by the inverse square of the distance ratio. I.e. at twice Kerbin's orbital distance your panel will output 1/4 of its chargeRate; at 1/10 Kerbin's orbital distance you get 100 times chargeRate.

In FAR, your terminal velocity will be high enough that you won't be able to catch up to it with any reasonable weight in engines, and high TWR makes it harder to keep the rocket stable. So the conventional wisdom for FAR is a TWR on the pad of 1.2 or 1.3 to 1.6 or 1.7, and then full throttle unless you get structural failures.

The "deep-field survey" that the telescope can do anywhere in space (once the bugs in the plugin are fixed) seems to correspond to what Hubble was capable of. If I were doing a version, I'd kick the science of the 550AU experiment even higher to reflect the final-boss nature of doing it without warp drive, and add an intermediate experiment that requires you to be somewhere in Sun SoI. As far as scaling the science yield with where you are in the Sun's SoI, I'm trying to get my head around why one location in the Sun's SoI would be better than another.

Pure alphabetical. So stock parts that are in NASAmission/ will appear in a separate group from parts that are in Squad/. Mods between N and S (e.g. RealChute, SDHI) will appear between the two groups of stock parts.

The "direct planet observation" mission is based on the theoretical possibility of using the Sun as a gravity lens if we could get a telescope out to 550 AU or more. If we could reach 550 AU in the real world, the results would be orders of magnitude beyond anything that Spitzer could produce. The in-game distance requirement of 550 times Kerbin's semimajor axis is already scaled down from what you would calculate based on the mass of Kerbol. Getting out to 550 AU within the life span of a helium cryostat without using warp drive isn't impossible, but it's one of those "final boss"-type missions. I ran some back-of-the-envelope numbers for a 400-day, 7500-GM brachistochrone (burn prograde for the first half and retrograde for the second half). The required acceleration would be between 2 and 3 cm/s^2, with delta-v of about 900 km/s. With enough acceleration and a coast phase in the middle of the trip, you could probably get that down to about 500 km/s. Since you don't get quantum vacuum plasma thrusters until you get warp drive, the best way to get that kind of delta-v pre-warp drive seems to be a DT Vista.

Even if KospY was mistaken in trying to control what code dependent on KAS can be distributed, it's a forgivable mistake to make. The people behind the GNU GPL take the position that a program that calls functions in a library is a work based on the library, which is a pretty similar scenario to a KSP part using a module from somebody else's plugin.

The license contains a specific requirement: "If You use our Work, You must acknowledge Us." As long as we're talking about exercising the permission that's given in the license, we're not talking about claiming credit for Fractal's work. And please don't insult the mod author's intelligence by suggesting that his expectations wouldn't be accurately reflected in the license he chose.

If you want to combine KSP's snap-together rocket building with real-scale speeds and distances, my preference would be to combine RSS with something like Real Fuels that scales your tank and engine masses to realistic values.

My plan is to stick the MapTraq on blizzy's small touchscreen Mechjeb box.

If you use the +/$ "copy" operator to clone a part, it should do what you want. https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax#Copy___or_ It would be something like +PART[foo] { name = bar !MODULE[...] { } MODULE { ... } // All of the changes you want to make to the copy }

As camlost and phoenix_ca discussed, this is how lifting line theory models the effect of tip vortices. The model does correctly capture the advantage that high-aspect-ratio wings have: In a high-aspect-ratio wing, a smaller percentage of your wing area is close enough to the tip to be penalized.

Mun->Minmus->Ike->Duna->Gilly in a single-seat lander can. About three Kerbin years in interplanetary space, in a save with no other flights in space.

Torque is fixed, but angular acceleration = torque / moment of inertia, and any distance between the torque source and the center of mass increases the applicable moment of inertia.

If you're on Windows, Arrowstar's Trajectory Optimization Tool has a search mode to find the earliest arrival possible with a given delta-v budget. No need to click around on the porkchop plot until you find a transfer you like.

There are a lot of urban legends about reaction wheels. I put mine as near as I can to the center of the ship, and approximately symmetrical around the center if I have to spread them out, based on this comment by C7. It's RCS where you want to think of the ship as a lever. Reaction wheel torque is more like attaching the axle of a motor to the ship at the reaction wheel: the quickest and smoothest rotation happens if you're balanced around the place where you're applying torque.

Biomass uses TAC resources out of the box. (Although if you're seeing "WASTE_TAC" you have some configuration files around from TAC LS 0.1 or 0.2. The resource should be named "Waste".)

My single-use landers are two-stage so I have a clear separation between descent delta-v and ascent delta-v. It's easier to remember "As long as I have this stage I have enough delta-v to make orbit" than "If I let the fuel bar go below this percentage, I have to abort."

Currently, 1 unit of ChargedParticles is defined as enough particles to carry 1 MJ of energy. That 1 MJ of charged particles will have a different mass depending on what kind of particles they are and how fast they're moving. You're not going to simulate an engine by just assigning ChargedParticles a density and setting an engine to run on it. It's probably details like that that are keeping the charged particle nozzle on the wish list.

You can mine aluminum on Mun and, IIRC, Ike, using the ISRU refinery. What you produce by mining is alumina, the ore, which the ISRU refinery can then electrolyze into elemental aluminum and oxidizer. The only tank for elemental aluminum is built into the hybrid rocket itself. I still think the most likely problem with the config file that was posted is the converter not actually having access to aluminum,

You probably still need TreeLoader's plugin to get the game to read the tree.cfg in your save.

A lot of Interstellar's fuels are STACK_PRIORITY_SEARCH, so it's possible that the module is working but you need fuel lines to access the resource.