undercoveryankee

Since the last round of testing, ModuleManager 2.3.4 has been released. Upgrade that, install the next group, and continue testing. Mod Group 4: Resources MKS 0.20.8 (with bundled Firespitter plugin and Karbonite). Did not install ORS because KSPI Lite's version is current. Replaced Community Resource Pack with latest version 0.1.2 Asteroid Recycling Technologies 0.4.4 Extraplanetary Launchpads 4.2.3 EPL Karbonite conversion 16-5 (September 1) Terrain was still present on switching to Minmus probe. Consistent with hypothesis that references to the MKS PunchCards resource were causing exceptions in the Tracking Station, no exceptions were observed after installing this group. Mod Group 5: Science Custom Biomes 1.6.6 SCANsat 7rc4. Deleted ModStatistics. Tarsier Space Tech 4.4 If there's a mod conflict involved, this group is where I expect to run into trouble. SCANsat actually talks to the terrain system, and it's still on an older ORS. My first time using Tarsier's telescope was between the last time I switched to a lander on my original install and the first time I ran into the bug. No issues observed, though. Mod Group 6: Parts, Automation, and Leftovers 6S Service Compartments 1.1 and extension. Skipped the older Firespitter in the package in favor of the version bundled with MKS. FinePrint 0.58b kOS 0.13.1 MSI Infernal Robotics 0.18.6 Procedural Dynamics 0.8.1 Spaceplane Plus 1.3 Taurus HCV 1.2 And with that group of mods, I can return to the original save and do what I was trying to do before the glitch hit.

Since in KSP, the player is the designer of the vehicle, I think it would be more fun to make sure the player has access to exact coordinates and all of the necessary performance figures for the engines and let the player calculate the vehicle parameters that need to go into the script than for kOS to automagically give everyone a generic useful set of data. I don't think anyone who's using kOS at this level is going to be scared away by the prospect of doing some math in a spreadsheet or in a separate "vessel analyzer" kOS script that's run from the archive.

Of the Squad resource names, I'd expect the basic Propellium and Oxium to be more widespread than we want for the karborundum precursor. But something like hexagen or zeonium could be made suitably rare. If the best source of the precursor is in Jool's atmosphere, that would also add another step to the process that couldn't be done on rails.

The way I've been in the habit of doing networks requires basically zero micromanagement: Omnis in low-to-medium equatorial orbits around Kerbin, Mun, Minmus, and anywhere else I develop a full-time presence. That way I don't need dishes for the busiest orbits at all. Don't worry about synchronous orbit. If the omnis are in range of each other, one of them is in range of KSC. A DTS-M1 in cone mode covers low Mun or Minmus orbit from low Kerbin orbit and vice versa. Two or three relays in each SoI with dishes for each of the others, and each body's low-orbit omni constellation is linked to the others. Interplanetary probes use 88-88s in pairs. I target each one on a different LKO relay satellite, have an "active vessel" dish on each relay satellite, and forget it. Kerbin-orbit relays with outer-planets dishes (e.g. GX-128) in medium-low orbit (1000km or a little under) so a probe's GX-128 in cone mode covers both before the 88-88s go out of range. Kerbin-orbit relays include a dish of the appropriate range targeting each planet, so I don't have dedicate a dish to a mothership that wants to relay to a sub-probe as long as it's in a planet's SOI. A couple of spare dishes on each relay so if I do something that does need a dedicated link or two, I don't have to launch more satellites.

The typical VTOL that I see has two banks of engines: one for "forward" thrust and one for lift when the forward axis is horizontal, with at least one "control from" part aligned with each bank of engines. Things you might want to do with kOS: Programmatically switch control parts. Don't know if we have that yet, but it will be possible at the same time as any other command that's in a part's context menu. Programmatically activate one bank of engines while deactivating the other. Do it with action groups now; do it without action groups once we can fire context menu events directly. Programmatically detect which engines are aligned with which control parts so a family of VTOLs can share a script. Try looping over the parts and comparing orientations in your code. If you find that you need something specific that's not in kOS to support a particular ship, you'll be close enough to offer a targeted proposal. Have several banks of engines running at the same time at different throttle settings. While MAINTHROTTLE is always going to control all active engines at once like the stock throttle does, throttling of individual engines might be possible through exposing their thrust limiters or whatever Davon Throttle Control uses. Carry out maneuvers using engines that don't have a corresponding control part. Takes one or two extra lines of code to calculate an orientation for the control part that points another group of engines the way you want. Commanding a pitch of 0 and firing lift engines is no harder than commanding a pitch of 90 and firing forward engines. Temporarily make kOS use a control axis that doesn't correspond to the physical control part, e.g. so you can call a script that assumes that all engines fire along the control axis. I can see where that might be useful if you're a big code reuser, but it also seems like enough of a pain in the neck to implement that I won't be surprised or disappointed not to get it. Calculate the net thrust vector of a list of engines. You should be able to do in kerboscript everything that RCS Build Aid does in C#. We have the vector types and operations; if you find that a variable that kOS doesn't expose affects your result, let us know what variable you wish you had.

ChargedParticles aren't used in KSPI Lite, but the resource definition is still in CRP. Not a good choice, as it's a zero-density resource that was produced in old-KSPI reactors. ExoticMatter is in CRP; old KSPI had it generated by the Alcubierre drive that used it. I haven't checked whether KSPI Lite changes that. Add a way to generate or harvest it without an Alcubierre drive, and it might work. Helium-3 is actually a decent choice. It's an old-KSPI resource that's still in CRP but not used in KSPI Lite. It's tweakable by default, but setting it to non-tweakable shouldn't break anything. The only source currently configured is Jool's atmosphere. Given the real-life debate over how much He3 might be recoverable from rocks on airless bodies, you might add a limited surface concentration to Tylo to give a choice of challenges for recovering it. We also have a CRP definition for Plutonium-238. Was defined in old KSPI for use with some RTG-lifespan code that was never applied to any parts. No sources are currently defined, but the resource definition exists and is unlikely to be used for anything else.

In atmosphere, if your method of compensating for offset thrust is through an aerodynamic surface producing a lift force in some direction, that lift should induce additional drag compared to the same aerodynamic surface running at zero lift. I say "should" because stock aero may not model this. If you have gimbaling engines, the steady-state position will be with the engines gimbaled so the thrust axis passes through the center of mass. Inefficiency may arise in atmo if gimbaling takes you too far from your lowest-drag orientation, or in space if your thrust axis ends up too far from your control axis and you find yourself chasing the node to correct for an off-axis burn. If you correct using RCS, then you're expending RCS fuel that doesn't contribute to your delta-v (or might, positively or negatively, depending on your thruster placement). If you need that RCS fuel later, or if your RCS shares fuel with engines that you do rely on for delta-v, you might end up with a problem. Correcting with reaction wheel torque just requires electric charge, which is usually a replaceable resource. So basically, generating torque to balance out offset thrust doesn't cost efficiency (in the sense of available delta-v from the engine that needs to be balanced) unless it adds air drag or expends reaction mass in some other direction.

Where does the Interstellar license say you can't distribute a new compiled version without Fractal's consent? All I can find are requirements that you give credit, link to the original distribution, and distribute source code with your compiled distribution.

Get Interstellar Experimental 0.11 from https://github.com/WaveFunctionP/KSPInterstellar/releases . It works and it has all of the parts that were in Fractal_UK's 0.11, but it still has all of the pre-0.24 part costs.

I thought the KSC runway was labeled right: 09 at the launch end where you're facing east, and 27 at the threshold you use when you're going west. The last digit is dropped.78/

Windows 64-bit sometimes crashes in ways that can't be reproduced even on another Windows 64-bit system. If it's a local 64-bit gremlin, there's not much to be done. But we can fix the previous exception "Could not load type 'CrewRoster'" in case that is somehow triggering the ultimate crash. That is caused by a mod trying to access an older component that has been replaced in the current version of KSP. Look for mods that edit or manipulate kerbals (e.g. I see CrewXfer in your list) and try removing them or upgrading to a version released after 0.24.2.

You're running out of memory, which isn't really a particular mod's fault. It happened to be chute deployment (or just more terrain showing up at higher detail about the time you passed through your deployment altitude) that created a spike in demand and pushed you over the edge, but if you're that close to the edge there are plenty of other things that could push you over equally well.

That exception means you have a mod that does something with individual kerbals that hasn't been updated for 0.24. The only one I spotted in your GameData was Final Frontier. What version of FF is installed? I don't know whether that exception has anything to do with the other issues you're experiencing, but it can't hurt to fix it.

Finally got some time to continue troubleshooting. I'll update this post periodically as I make progress. I made a new copy of KSP 0.24.2 from the never-launched master copy in my Steam library and installed only enough mods to be able to load one of the probes in my save file. All mods were freshly extracted from the original downloads. It's a longer list than I would like. Mod Group 0: Required for the test ship KW Rocketry 2.6c RemoteTech2 1.4.1 ModuleManager 2.3.3, replacing the older versions packaged with some of the mods Interstellar Lite 12.2 and the dependencies packaged with it: Toolbar Community Resource Pack Open Resource System 1.2.0 TreeLoader TweakScale (custom package) [*]MechJeb 2.3.1 [*]Science Revisited 1.3.1 [*]KDEX 1.0.2 Results: Tracking Station failed to load when I clicked on it. After deleting all active contracts from my save file (assuming that FinePrint contracts were part of the problem) I was able to access the Tracking Station and switch to a probe. The original problem with missing terrain doesn't show up with this selection of mods, but I still have intermittent problems with the Tracking Station ("Fly" button remaining disabled when I click on a ship, clicking a ship doesn't select it). I suspect these glitches are due to having data in the save file for other mods I don't have. Since the original glitch seems to be gone, I'll go ahead and add the next group of mods: the ones I find hardest to do without. Mod Group 1: Top priority Active Texture Management 3-3-1 FAR 0.14.1.1 Procedural Fairings 3.09 ATM is installed with its stock configs for now. I have some local tweaks that I'll probably apply later in the process. I deleted ModStatistics from the FAR directory. I don't mind the data it shares, but for troubleshooting purposes I would rather avoid plugins that don't add gameplay. Result: Switching to probes still works. Still getting exceptions in the Tracking Station. What seems to be the root exception is this when I try to select a vessel: NullReferenceException: Object reference not set to an instance of an object at KnowledgeBase.<GetUnloadedVesselMass>m__326 (.ProtoPartResourceSnapshot x) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable+<Sum>c__AnonStorey3A`1[ProtoPartResourceSnapshot].<>m__74 (Single a, .ProtoPartResourceSnapshot [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.Sum[ProtoPartResourceSnapshot,Single] (IEnumerable`1 source, System.Func`3 selector) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.Sum[ProtoPartResourceSnapshot] (IEnumerable`1 source, System.Func`2 selector) [0x00000] in <filename unknown>:0 at KnowledgeBase.GetUnloadedVesselMass (.Vessel v) [0x00000] in <filename unknown>:0 at KnowledgeBase.CreateVesselInfoList (.Vessel v) [0x00000] in <filename unknown>:0 at KnowledgeBase.OnMapFocusChange (.MapObject target) [0x00000] in <filename unknown>:0 at EventData`1[MapObject].Fire (.MapObject data) [0x00000] in <filename unknown>:0 at PlanetariumCamera.SetTarget (.MapObject tgt) [0x00000] in <filename unknown>:0 at SpaceTracking.SetVessel (.Vessel v, Boolean keepFocus) [0x00000] in <filename unknown>:0 at SpaceTracking+ .MoveNext () [0x00000] in <filename unknown>:0 Still hoping that problem has something to do with the save referencing mods I don't have installed. Mod Group 2: Difficulty Deadly Reentry Continued 5.2 TAC Life Support 0.10 RealChute 1.2.4 No change either in terrain loading or in Tracking Station exceptions. Suspect that Tracking Station exceptions occur when a part on the vessel references a resource whose definition isn't installed, such as the MKS/OKS PunchCards resource that gets added to the Comms DTS-M1 dish antenna. Mod Group 3: Info and editing tools Kerbal Engineer Redux 0.6.2.10 Docking Alignment Indicator 4.0 Enhanced NavBall 1.3.2 CrewManifest 0.5.8.0 Kerbal Alarm Clock 2.7.8.2 ResearchThemAll 1.1.0.0 SelectRoot July 18 TAC Fuel Balancer 2.0.4.3 RCS Build Aid 0.5 Can still switch to my probes. Exceptions in Tracking Station not fully tested after this batch. The landers I've been checking the missing-terrain problem with have both been flown since the last time I reverted to the original save file and no longer contain PunchCards. At this stage in the mod-installation process, I'm leaning toward file corruption as the cause of the original missing-terrain glitch, and I'm optimistic about my chances of continuing the interrupted career in a new copy of KSP. I think I still have two or three separate groups worth of mods to install before I'm back in action.

ORSModuleRailsExtraction simulates extraction continuing to occur while the vessel is on rails. It's what all USI drills currently use, but if you don't want to depend on the USI dlls, you can use ORSModuleResourceExtraction and just not have the benefit of that feature.

It's possible to do math on a value that consists of a single number. On a key value that consists of multiple numbers, there would have to be some way to specify which token to do math on and which to just match. That would be too complicated for MM's syntax. Only thing you can really do with a curve is replace entire keys.

There are buttons in the lower right corner of the screen to turn on and off different groups of connection lines.

I first noticed the problem when a rover crashed on Minmus and I switched to a previous probe to get the KSPI seismic data. I've tried older saves of the same career from before the last time I was able to switch to a landed probe, with the same result. The probe appears intact, but floating in space with the skybox visible on all sides. Log is at https://www.dropbox.com/s/ktm87kv8ksiggn7/Player.log?dl=0 . I'll work on putting together a complete mod list when I have more time to dig into it. Any suggestions on where to start?

I've got a set of reactor and radiator numbers based on 0.11 (similar, but with a few changes to take advantage of TweakScale and to keep "original" and "upgraded" versions as separate parts) that I like. I'm currently at the "play for a while with it installed to make sure it's reasonably free of bees" stage. Right now I expect to publish a public beta this coming weekend.

Versions of SCANsat that support ORS mapping include a ModuleManager config that makes the GRS a SCANsat sensor for the resources that it detects. That config uses the 0.11 name for the GRS part, so it will have to be updated to add SCANsat support to the 0.12 part.

The GRS changed its name and switched from the "blue sphere" mesh to the same model as the other spectrometers. Its functionality is ORS-based, so it is sensitive to whether you have only the correct ORS and whether you have Uranium, Thorium, and Alumina maps present. Thorium is intentionally gone in this version, but the GRS works for me to detect Uranium and Alumina. It doesn't have TweakScale because it doesn't have any functionality that would change with size. It doesn't have any tweakables because it doesn't have any functions that need tweakables. In flight, it shows you the Uranium/Thorium (if present)/Alumina abundances directly below you and allows you to toggle hot spots. Nothing that it had in 0.11 is missing.

There are a lot of one-piece NTR parts like the stock LV-N and the FTmN collection. That's what I was interested in self-reactor support for; I thought it would be interesting to integrate those models with KSPI's modules.

At a given exhaust temperature, the propellant with the lightest molecular mass will produce the highest Isp. As Isp decreases with increasing molecular mass, thrust per megawatt increases proportionally. Propellant combinations that add further energy chemically (e.g. LFO) still lose some Isp over straight hydrogen, but the extra energy means you gain more in thrust than you lose in Isp. So generally, you'll use hydrogen (represented by LiquidFuel in both versions of Interstellar for now) when you care more about Isp than TWR, and LFO when you want decent TWR with higher ISP than they would give you in an ordinary chemical rocket.

Fission reactors have to be started and stopped from EVA. "EVA Maintenance Needed" comes up when the reactor is ready to be started by a kerbal on EVA.

Not supported. Generator looks only at parts stack-attached to it for a reactor, and not at itself. Might ask WaveFunctionP to change this in his "lite" branch, but that's how it is for now.