undercoveryankee

I'd be suspicious of the "LOCK THROTTLE TO THROTTLE + <stuff>" lines. If I remember right, a LOCK is implemented as a trigger-like chunk of code that gets fired whenever any of the variables on the right-hand side change. If you LOCK a variable to an expression that includes itself, an implementation that wasn't testing for that pathological case would likely evaluate the lock recursively. I'd do something like "SET targetThrottle to <stuff>. LOCK THROTTLE to targetThrottle." and then do the updates as "SET targetThrottle to targetThrottle + <stuff>."

Best way to do that would probably be to make sure the API for other plugins to add alarms to KAC is general enough to support the use case, then make the code to predict comms up/down times part of RemoteTech. Needs more knowledge of how your RT network operates than KAC should really be maintaining.

I think you're right. Aircraft can be told to hold in a pattern at a waypoint until there's more room on the next leg of their flight plan, or to approach a waypoint at a different altitude or in a slightly different direction. For an orbiting spacecraft that needs to rendezvous with something or reach a mission orbit meeting certain specifications, the space of possible flight paths isn't smooth like it is for aircraft. There are discrete windows where it's possible to do the mission within your delta-v budget, and the window you take will determine the orbits you use. So each operator of a spacecraft would be responsible to generate a plan that doesn't closely approach anyone else's current orbit or previously filed plan. If two operators file plans that conflict, the first to file gets approved and the other gets told to recalculate around the plan that was approved. You'd have limited ability to move other ships out of the way of a manned ship that declares an emergency, so I'd allow manned ships to to reserve a couple of pre-calculated contingency maneuvers in addition to their planned maneuvers. Busy orbits like geosynchronous, near major space stations, and typical phasing orbits for rendezvous with busy targets would have limitations on how much time you can spend at those altitude ranges at certain inclinations if it isn't your mission orbit. For military spacecraft (e.g spy satellites, X-37B) that don't want to publish their orbits, I'd allow them to fly without filing as long as they agree to monitor the database, maneuver to avoid any flight plan that gets filed, and pay fair compensation to anybody on a flight plan who's harmed in any way, subjected to a near miss, or forced to maneuver because of an unlisted flight.

There's a ModuleManager patch somewhere in this thread that adds the extra top node to the stock engines. I have it installed but I didn't keep a link to the post where I got it.

I'd love to see probe-landing contracts that appeared only if RemoteTech is present, RemoteTech signal delay is enabled, and kOS is available. And it would need a check that the lander doesn't have a MechJeb module on it as configured for landing. Contracts where part of the reward is the reward, and the other part is a library of scripts you'll be able to draw on for future missions. That could be a great teaching tool for doing things with kOS. I'd lean toward "when you change the state on one SCS part, look for any others on the vessel and automatically change them to match." You might still find a way for a conflict to exist for a frame at a time, but the conflict resolution rule doesn't have to be as user-visible. What happens if two SCSes try to "LOCK STEERING" to different directions at the same time?

For balancing against KCT, it wouldn't hurt to be able to configure lead time for missions on top of the recorded mission time, with the option to pay extra for a rush launch.

I'd prefer "do something that kOS is the obvious way to do" over "do something with manual controls locked out" as much as possible. None of the stock contracts really care what approach you take if you get the specified payload to the specified place.

There are several different things that can go in a :HAS[] selector. "@MODULE" or "!MODULE" mean "Look for parts that either have or don't have a MODULE node meeting this selector." You also have "#parameter" and "~parameter" to look for nodes that either have or don't have a value named "parameter" that meets the selector. So :HAS[@MODULE] requires the "@" both for consistency with the "find an existing node" patch type and for consistency with all of the other types of arguments that require punctuation there.

If the kerbals are using life support in their pod but not from containers elsewhere on the ship, that does sound like a flow issue. Flow issues shouldn't happen with the resources all having ALL_VESSEL flow. Here's a guess: If this is on 0.90, is the space center upgrade for manual resource transfer unlocked? If not, that may be changing the behavior of some of the APIs that TAC uses to test how much is left.

I'd be willing to take that a step farther: If you think spinning up a new install to isolate an issue where you're demanding help is an unreasonable request, why are you playing an early access game?

There is nothing in the 0.25 release of FinePrint that isn't included and improved on in 0.90 stock. Installing the mod version of FinePrint on 0.90 will lead to sadness.

Part scaling and negative costs are issues that were around in 0.25. The patch from https://github.com/FractalUK/KSPInterstellar/wiki/Illustrated-Guide-Chapter-0%3A-Installing-and-Patching includes fixes for those.

The version of Firespitter in the package is for 0.25. If you get a Firespitter that works with 0.90 from that thread, these parts will work with it.

New Illustrated Guide chapter is up, covering seismic sensor and IR Telescope. https://github.com/FractalUK/KSPInterstellar/wiki/Illustrated-Guide-Chapter-2:-Science

Yes, they are supposed to be unguided. Any control will have to come from creative use of launch orientation and timing.

I found the same thing while I was updating the integration package. The problem is that CRP includes an outdated definition of Antimatter that makes Antimatter cost nothing, and the patch to the tanks assumes that AM costs √4819.22 per unit the way KSPI defines it. I added a new patch to the integration pack (https://www.dropbox.com/s/34crak0e0qf8qud/KSPI_CRP_20141220.zip?dl=0 ) that disables any definitions of Antimatter that don't have a cost, so KSPI's definition will win. If you update the integration pack, you can put the patch to the tank back in.

Just uploaded KSPI_CRP_20141220 to fix a couple of issues that have been reported: Fixed atmospheric argon collection with KSPI scoops. Force use of a definition of Antimatter that has a unit cost so that costs of antimatter containers will be correct. Interstellar 0.13 is known incompatible with KSP 0.90. If you're keeping 0.25 around to play Interstellar, you'll need to stick with the ORSX-based versions of the USI mods because Regolith depends on the changes to biomes in 0.90. If and when Interstellar is updated to support KSP 0.90 or higher, I'll work on Regolith integration for that version of Interstellar. Until then, I'll continue to support integration for the ORSX generation.

So on Kerbin, the KSPI atmospheric scoops will scoop oxygen as Oxidizer, but not argon. Those are some details I can work with. I replace Interstellar's argon resource with the CRP/NearFuture argon, and it looks like I left the old resource name in the ORS atmospheric configs. In KSPI_CRP_Pack/CRPResourcePack_Atmospheric.cfg, change all occurrences of "resourceName = Argon" to "resourceName = ArgonGas" and see if that makes a difference. I'll post an official update when I get a chance.

I'd imagine that the kerbals in the early days also want to be careful that an explosion at one facility won't damage the other facilities. With that in mind as a factor, starting each facility roughly centered in the area you're planning to expand into makes some sense.

Let's get some basics out of the way: What planet are you on and what resources do you have storage for? And so I know whether the problem is with the resource definitions or the scoop setup, can you also give us a screenshot of the resource listing from the gas chromatograph/mass spectrometer instrument?

"In tandem" is a slippery concept. If the writers and artists who are done with the base game start designing the next installment while the programmers and QA teams are still working on the base game, that's not taking anything away from the base game. I don't even mind if some optional bits are developed in tandem with the base game. If I would think the base game was good enough to buy at the release price if the DLC didn't exist, that base game doesn't become less fun just because more stuff is offered for it. If I think the base game is too short or lacks variety and I'd be happier waiting until it goes on sale, I would probably do the same thing if the DLC didn't exist. I do think preorder bonuses and retailer promotional items should become free to anyone who's still playing the game after six months or a year, because if I'm still interested in the game after the marketing has blown over, the reviews are in, and it's not new and exciting any more, that means I genuinely like it and I'm the kind of customer you should care about keeping. I'm not even sure what would be in a paid expansion for KSP. Maybe alternative solar systems or contract packs that would add a "story mode" on top of career. Things that are just parts/new functionality/new physics would have a hard time competing against the mods that we already have.

A few times: Forcing success on a couple of FinePrint satellite placement contracts that weren't completing due to a bug in FinePrint. Used Whack-A-Kerbal when I accidentally connected a KW interstage by the node that doesn't decouple. The alternative Part clipping in cases where the editor was incorrectly showing collisions on symmetry counterparts or when one of the intersecting parts is visibly hollow. If it's an in-universe problem I'll look for an in-universe solution. In my current career, I sent a set of RemoteTech relays to the Mun without batteries. The built-in storage in the probe cores was enough to get into Mun orbit, but not enough to establish the final mission orbits and run the antennas. My Apollo 8 equivalent will attempt to rendezvous with the dead satellites and install batteries with KAS. But if I'm only in trouble because it's a piece of software, I don't feel like it breaks the story I'm telling myself to fix those problems or limits in whatever way is most convenient.

CTT includes all of the stock node names, so parts that aren't CTT-aware will continue to appear in the same nodes where they appear in the stock tree. That may be earlier than a CTT-aware config would put them, but all of the parts will be usable and the arrangement will still mostly make sense.

Some parts of Near Future Technologies play something like what you're thinking of, but relying on electrical engines and not thermal. Between Interstellar 0.11 and 0.13, WaveFunctionP did KSPI Lite that has almost all of Interstellar's gameplay, but with fewer parts where you have to choose operating modes and more stock-friendly numbers. Nothing that's exactly what you're looking for.

The parts of the programs that get disabled are the ones that are implemented by creating maneuver nodes and executing them. If MJ tries to call those functions while maneuver nodes are locked, the resulting failures are worse than disabling the function. The only way to have functions that are implemented in terms of nodes available before nodes are available would be to give MechJeb its own internal maneuver node system that it can use instead. That's unlikely to happen any time soon.