undercoveryankee

Apart from building levels, I find it a little harsh that I have to spend KCT upgrade points to improve build rates separately at every launch site. Might be useful to be able to put upgrade points into a shared pool that would give a bonus to all build rates at all sites, but at a lower rate than spending points on one site's build rate directly. Call it something like "production infrastructure".

As far as I remember, the Cryo Tanks have always been included in the download for Cryo Engines, and also for Kerbal Atomics. Because CKAN doesn't allow files from one package to overwrite files from another package, it has to treat the shared components as a separate mod even if the package author has never distributed them that way.

In the really old days, before we had multiple PartModules and MODULE nodes, there were other modules that the "module" property could be set to. Most of these were migrated to be PartModules, but wings and control surfaces didn't get converted until the aerodynamics overhaul in 1.0. In the pre-1.0 world, setting "@module = Part" in the MM patch for FAR was how you disabled those parts of the stock aero system. Now you mostly see it because it's not hurting anything and it's not worth the time to clean up.

If the RCS seemed to have the vehicle under control until the second-stage main engine spooled up, that rules out a lot of the obvious possibilities. Double-check that you're not coincidentally running out of ElectricCharge or RCS propellant. It seems obvious, but it's not hard to overlook in the excitement of a tumbling rocket. What are you using for attitude control? MechJeb, stock SAS, or something else? If it's some kind of PID tuning issue, a lot of the advice will depend on whose PID has the issue. Pictures – of the design of the stage, and of your full screen just before and just after ignition – will help a lot.

Chances are your second stage is aerodynamically unstable. They usually are. With realistic reaction wheels, if your stage doesn't have RCS, you're relying on engine gimbal for attitude control. That means you don't have full control authority until the engine spools up to full thrust. If you're pointing off prograde or have a significant rotation rate at the moment of separation, it can throw you into a pretty significant tumble in the couple of seconds it takes to recover control. If your first stage is also unstable and relying on gimbal for attitude control, you start drifting toward "out of control" as soon as the first stage burns out. If you're too low in the atmosphere at staging, the instability can overpower your ability to react. If you're staging below 35-40 km, you may want to add more burn time to your first stage. Try to make sure you're right on prograde before burnout, and keep the staging sequence as quick as possible so you spend less time uncontrolled. If you can arrange for second-stage RCS to come on at the moment of separation, that will help.

Thanks! Got it downloaded and I have a working RVE. Was "this KSP 1.1.3 assembly" in the post supposed to be a hyperlink?

I'm on KSP 1.1.3 for the more mature RP-0, with Scatterer 0.0255. The Github release description for RSSVE 1.2.2-RC3 says "New binary assemblies for KSP 1.1.3 users (for use with Scatterer v0.0255).", but everything else says these releases are for 1.2.2 only. Is there a version somewhere that I'm missing that's compatible with 1.1.3 and Scatterer 0.0255, or should that line not be in the changelog?

I have a few survey contracts to take temperature measurements near waypoints on the Mün and Minmus. I'm trying to write a kOS script that will activate the thermometer whenever I'm close enough to a waypoint. Problem is, kOS doesn't automatically tell me whether I'm within range of a waypoint, so I need to know what distance from the waypoint I should be looking for. I found these two lines from GameData/Squad/Contracts.cfg: MinimumTriggerRange = 500 // The minimum range to trigger waypoints on ground surveys before gravitational adjustments MaximumTriggerRange = 15000 // The minimum range to trigger waypoints on high altitude surveys But I'm not sure how these numbers are used in the game. Is the radius of an "in spaceflight near <waypoint>" parameter always equal to MaximumTriggerRange (15 km), or does it scale with the size of the body and/or the altitude threshold on the waypoint?

The death altitude is based on a pressure of 0.01 atm. It's around 22 km in the stock 70-km atmosphere, but KScale64 sets an amosphere height multiplier of 1.33 to give a 93-km height. I expect that the 0.01-atm cutoff altitude is also multiplied by the atmosphere height multiplier, so I'd be worried about anything below 29.3 km. I've done several rescues in KSP 1.1.3 and the corresponding mod versions where the periapsis was in atmosphere and the apoapsis was in space, and found that it wasn't that hard to catch them at their apoapsis. All of the ones that I saw had periapsis above 70 km, so I assumed that the contract code was hard-coding the stock atmosphere height as its minimum periapsis. This example has its periapsis not only inside the atmosphere, but inside what the stock atmosphere height would have been. So it looks like there's no 70-km minimum, and something else is going on.

Any orbit of the same body with the same SMA will have the same period. The other elements affect the shape of the orbit, but not the period, so you can leave them set to wherever they were in the file and the orbits will still sync.

Sounds like the configuration file config.xml is empty or missing. If there's an empty file at the path in the error message, try deleting it and see if the plugin will re-create it. If the file does not exist at all, or if deleting doesn't work, see if you can find the original config.xml in the Trajectories download and put that version of the file in that location.

If I understand it right, the version of VPP in 1.1 was current when 1.1 first adopted it. But because of the particular way the wheel code is built out of a combination of VPP code and Squad-developed pieces, it wasn't feasible to incorporate the updates to VPP that came out during the 1.1 development process without further delaying 1.1.

Performance will be realistic because of RO, but parts may appear in an unreasonable tech node or have unreasonable costs.

I've seen a similar report (gimbal not responding in all axes after upgrading to KSP 1.1) for one of the engines in Porkjet's Atomic Age. Apparently something about gimbal changed on Squad's side during the port to Unity 5, and the game has gotten more strict about the orientation of the transform that ModuleGimbal acts on.

Archive is disabled with that error message if you're using RemoteTech and don't have a connection to KSC.