undercoveryankee

I wonder if the current test for producing megajoules (current_charge >= max_charge) might be a little too conservative. Do we know enough about the order in which FixedUpdate gets called that we know the check runs after the stock module has supplied EC and filled the bar? Another possible cause of a solar power satellite not generating MJ is a lack of MJ storage capacity. The plasma thruster doesn't have any MJ storage, and I don't see any code adding MJ storage to the solar panels. See if adding a generator or microwave receiver (even an inactive one) allows the solar panels to power the plasma thruster.

I like to use the UP13 under a stock Mk1 capsule, because it rides high enough on the stock decoupler to leave a bit of a gap. The integer-size decouplers can be deleted if you're not using Realism Overhaul and don't need them for anything. I was about to suggest giving them :NEEDS[RealismOverhaul], but that would annoy people who are using integer-sized parts for some other reason.

My guess would be that the plugin decides what throttle setting to apply as a percentage of the engine's max thrust without checking whether something else has reduced the available thrust. Probably worth bringing up on the Firespitter thread.

They're zzz's model that Wave imported. A download of the models with configs based on Fractal's configs at the time is linked from https://github.com/FractalUK/KSPInterstellar/wiki/Alcubierre-Drive . If you start with that download and edit the parts' name, techRequired, and cost, you'll be compatible with this release sooner than if you started with Wave's TweakScale-using config.

RSS has a pretty flexible plugin. You might be able to come up with a config that doesn't touch the sizes and locations of the planets but adjusts Kerbin's height map to do what you're looking for.

kOS can already read altitude above the ground directly below you, which is good enough to start playing with altitude-based autoland scripts on flat ground.

I didn't intend "appeal to authority" so much as "what I expect more people to understand right away." Just like referring to any ascent pitch-over profile as a "gravity turn" is wrong, but people will know what you're talking about.

Thermal receiver has a defined heat exchanger temperature, currently hard coded at 1500 K. Isp of a thermal nozzle on a receiver is calculated by the usual square-root-of-the-temperature * constants * fuel Isp multiplier equation using that temperature.

A conflict between ATM and EVE is unlikely since they're both by the same author. But you are seeing an out-of-memory error. Make sure all of the ATM configs under BoulderCo are still there. Since both mods have folders that go under BoulderCo it's easier to goof up. If the ATM configs are all there, try dropping down to the lower-res EVE textures.

All of your symptoms are caused by the same problem: Something is keeping the Interstellar plugin from loading. Remove all versions of Interstellar and OpenResourceSystem, then install the Interstellar version you want and the ORS that comes with it.

Yes, you can do math on the current time and arrange for something to run at a certain time in the future. http://ksp-kos.github.io/KOS_DOC/structure/time/index.html Yes, you LOCK STEERING to a heading that's a function of your current velocity vector or altitude.

Make sure you're in Career mode and not Science mode. Make sure Treeloader is installed. Copy tree.cfg from GameData/WarpPlugin to your save folder, overwriting any previous tree.cfg in your save. If notree.cfg exists in your save, delete it.

Only one bee?

The AM reactors will happily draw fuel from the separate tanks, which I suspect is how you're meant to do it. Similar to a fusion reactor with a D/T cryostat, set up one of the AM tanks with any necessary fuel lines and you'll have a reasonable amount of runtime. (The AM tanks do start empty, but if you have CRP installed, the resource definition that's tweakable will usually load first.)

The closest I've ever seen is blizzy's ambient light adjustment plugin. Doesn't affect the strength of direct sunlight in itself, but it might suggest an approach. I've also heard that Alternis Kerbol does some interesting things with lighting (in addition to reshuffling all the planets). Might be some inspiration there for a sunlight-brightness mod.

Good point. Doubt it's causing the divide-by-zero/"tried to push infinity", though. The symptom of a bad boolean/"true" comparison would be a test returning false when the boolean is true, and the test has to be passing at least once for the thrust and isp lists to have nonzero length.

Conversion from megajoules to stock EC is the easiest conversion in the game. The Interstellar resource manager does it automatically if all higher-priority MJ requirements are met and there's room for EC.

It's possible that you have an engine in your list that reports ignition=true and reports zero isp. An engine that has flamed out will have ignition=true, flameout=true. When your condition is met, are any of your engines flamed out? This can include engines in dropped stages, if they were attached to the ship when you did the list engines and the debris is still in existence. You'll want to re-list engines at the top of the when block if you've dropped engines, and you'll want to check flameout as well as ignition when you're checking for active engines.

I was thinking of doing it the way TAC/MKS do: keep track of a last-updated time and fast-forward on reload. The fast-forward method doesn't really let you consume EC as you're fast-forwarding, because most of your supply comes from modules that don't fast-forward. What I would try do to enforce EC requirements is to keep track of whether EC supply is stable or discharging. If the battery level is stable or increasing with all EPL systems active, assume that it will stay that way and calculate progress while unloaded. If the battery level is decreasing, don't calculate unloaded progress. I know. But people up to and including RoverDude refer to this problem as processing on rails, so being strictly correct strikes me as not only a losing battle, but a lost one.

You might also grab the config from Realism Overhaul that gives the antennas suitable ranges: https://raw.githubusercontent.com/NathanKell/RealismOverhaul/master/RealismOverhaul/RO_RemoteTech2.cfg

I like the idea of consumables. Gives a bigger incentive to upgrade our MKS bases to the level of manufacturing spare parts. For prospecting, I think it's fair to have a low-resolution map detectable from orbit. Enough to tell, say, that one ten-km region is better than another. Then some ground-side mapping within that 10-km area would be needed to find the best place to drill.

I think landing with kOS best captures the "all you can do is wait to find out whether it worked" excitement of a real-life autonomous landing. But it's not for everybody. Some people can't run it with other mods that are higher priority. Others just don't find writing programs fun. Turning off signal delay and doing what a more sophisticated computer would do is a perfectly fair way to simulate an autonomous landing if it's what works for you.

No, in the default settings, there are no advantages to multiple omni antennas. One omni of the longest range you want to use is all you need. Some of the alternate range models give you a range benefit from having several, but someone who uses those can go into more detail. You're fine with one omni.

What I'd like to put in a word for is on-rails building so the shipyard can keep making progress while I run the supply missions.

I have a couple of craft files where I come out of time warp and the 1.25m fusion that I thought was running has shut down, but there's still tritium and I can restart it. Pretty minimal ships. When the shutdown happens, the only loads are reactor draw and a few KW of DC electrical. I'll try to come up with more specific steps to reproduce.