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.

If you save your script in a location that identifies it as bootable, you can set it in the VAB to be loaded and run at processor start. The specifics have changed between kOS versions; for 1.0, you can select any script in the "boot" folder of the archive ("Ships/Script/boot").

The kOS prerelease has a new feature where it uses reflection to look for plugins that support its extension API. That code is throwing an exception on FloaterTools.dll, and some of the kOS people are trying to decide how big of a problem that is. Is FloaterTools still used for anything after the conversion to stock buoyancy in SrvPack 0.5.0?

Yes, FloaterTools.dll is in the download for SrvPack 0.5.4. I'll have to ask RoverDude whether it's safe to remove it.

It's SrvPack 0.5.4, which according to RoverDude's github is the current release.

Any idea why the prerelease would be trying to load a .dll from RoverDude's Survivability Pack? Log highlight: kOS: Error while loading assembly: FloaterTools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null, skipping assembly. Full path: /Volumes/Elements/KSP1.1.3/GameData/UmbraSpaceIndustries/SrvPack/FloaterTools.dll (Filename: /Users/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64) kOS: Exception: Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'FloaterTools'. Stack Trace: at (wrapper managed-to-native) System.MonoCustomAttrs:GetCustomAttributesInternal (System.Reflection.ICustomAttributeProvider,System.Type,bool) at System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType) [0x00000] in <filename unknown>:0 at System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit) [0x00000] in <filename unknown>:0 at System.MonoType.GetCustomAttributes (System.Type attributeType, Boolean inherit) [0x00000] in <filename unknown>:0 at kOS.Safe.Utilities.AssemblyWalkAttribute.WalkAssembly (System.Reflection.Assembly assembly) [0x00000] in <filename unknown>:0 at kOS.Safe.Utilities.AssemblyWalkAttribute.WalkAllAssemblies () [0x00000] in <filename unknown>:0 Full log up to where I noticed the nag message on a terminal is at https://www.dropbox.com/s/ktm87kv8ksiggn7/Player.log?dl=0 .

Is there a good way to use the porkchop plotter from inside Mission Architect? When I was trying to plot a Juno-style Kerbin-Kerbin-Jool trajectory in MA, I had some trouble getting the optimizer to find the right deep space maneuver to set up the second Kerbin encounter. It occurred to me that if I could generate a porkchop plot for the transfer from aphelion back to Kerbin and auto-generate the cheapest maneuver that gets me to Kerbin within a specified date range, that would make it easier to start the optimizer with a trajectory that already gets into the right sphere of influence for the gravity assist.

If you fired the engine with SAS off and controls neutral, it would fire on the original 6-degree offset regardless of how much gimbal angle it has. But if you have an autopilot trying to hold a specific heading, it will apply enough steering input to bring the engine from its "center" position to a position that makes the rocket fly straight.

The only difference is that @linuxgurugamer was trying to hit engines with either ModuleEnginesFX or ModuleEnginesRF, and I just targeted the module that the auto-sort doesn't target. I need to ask for some clarification on that OR operator, because I don't see why mine would work and the other one wouldn't. Edit: Found the post in the MM thread that says the OR operator isn't supposed to work in :HAS clauses.

Sorry. Reading too fast. If you were running RFStockalike and the engine looked like vardicd's screenshot with no plume at all, the fix in 3.1.0 would have fixed that. Your setup with RFStockalike is the other screenshot with the plume showing up but too far forward. I'm doing some work on RFStockalike plume configs now. I'll take another look at the 909, and if I end up moving the plume farther back on the engine I'll share the fix here.

What you're seeing looks like an issue that was fixed in RFStockalike 3.1.0. Several releases of RFStockalike just before the current version had you install "RealPlume-RFStockalike" under GameData/RealPlume instead of to its current location directly under GameData. If you upgraded RFStockalike from 3.0.0 or 3.0.1, you may still have an old RealPlume-RFStockalike there. The older versions run in a later ModuleManager pass, so they will override the current version if both are present. If you have both GameData/RealPlume-RFStockalike and GameData/RealPlume/RealPlume-RFStockalike, try deleting the latter.