NeuroticGamer

I'm now experiencing what @Mihara saw. After successfully launching and completing the Kerbin contract. I continually get the Kerbin Contract, not the Mun. I need to learn more about how contracts are written You can see that the requirement of only 1 offered ZZZRadioTelescope contracts will prevent the Mun one from appearing. Does the order of the contracts in the CFG matter? If the Mun one was listed first (and already has dependency) would that be the way to correct this issue?

@linuxgurugamer , @FreeThinker I was experiencing a problem with the contract and broke out my grep tool. I found a copy of Triple-Z's contract in \GameData\WarpPlugin\Parts\BeamedPower\PhasedArray\phasedArray1\MunSeeker_ZZZ_RadioTelescope_Contracts.cfg The contract cfgs were identical except that "part = radiotelescope" was replaced with "part = deployablePhasedArray" I've verified that I got this alternate version from https://kerbal.curseforge.com/projects/ksp-interstellar-extended/files/2616269 It looks like the normal release of KSP Interstellar Extended. I'm still digging into whether there is a real bug in the normal copy of the contract.

You can go into the GameData folder for MemGraph and change the assigned keys in settings.cfg.

I might be experiencing the same thing and I would have been using Trajectories at the times it has happened. If I switch to another vessel, the UI fixes itself but it is now centered in my screen.

I don't know how I missed that with all the clicking I did in the VAB. Thanks for the clarification.

I've been using it in 1.3 without issues. I just followed the instructions given above to replace the DLL.

I'm trying to figure out if I'm experiencing a bug, an incompatibility, or a feature. I recently returned to KSP, starting a brand new career mode with KSP 1.3.0 and including TCA 3.4.2. The last version I think I played with was 3.2.x (KSP 1.2.2). I noticed that my crafts were not gaining the TCA modules as I unlocked them. I reviewed the in-game help and saw mention that previously launched crafts would not get newer TCA modules. That mechanic sames fair enough. However, launching a NEW copy of same craft results in no new TCA modules. If I created a brand new craft in VAB, I had the newer modules. I tried editing the older craft in VAB, go so far as to re-root and delete/replace my Probodyne HECS with anewly spawned copy. The craft still did not have the new TCA modules. I decided to backup my ships folder and take a stab at editing the .craft file. I found this section: I guessed that the VSLCONFIG section was the offending problem since a newly created craft did not have that section. Deleting that section did not cause any issues and the newly spawned copy of an old craft had the new TCA modules. So, feature or bug/incompatibility. It looks like a bug to me as the non-upgrading feature should be tied to crafts in the save file, not the .craft files.

I've been out of the game for a while. I need to go back and search my mod folder and see what is modifying what. I have the correct value currently but I can't remember if I manually edited the mod patch file or if I created my own patch for the patch :). Mebbe it magically fixed itself at some point, though when I made the post I was experiencing the issue and definitely doing work on my end to get it correct. Fortunately, it is pretty obvious that things are wrong by looking at the in-game values when right-clicking on an antenna.

@severedsoloThanks for all of your work on this mod (and others). I've quite enjoyed this contract pack in my current career game.

I'm pretty sure it is using both based on some VTOL disasters I've had. To be fair, I had failed to do basic CG to thrust vector alignment on the craft while editing, resulting in some hilarious spinning craft as it couldn't both gain altitude and control attitude.

I'm not at my gaming computer right now but I'm pretty sure RC doesn't break Lithobrake chutes (RC and StageRecovery opens them) but you can't tune them.

I've noticed that If I install OPM and JX2, the actual values are cut by a factor of 4. For example Communotron 16-S will show 125k in orbit instead of 500k. Is OPM altering range via a different mechanic? Should I be seeing 500k or 125k for Communotron? I've commented out the portion of the patch related to OPM (changing the displayed values back to stock) but I'm now wondering if OPM is using a non-obvious mechanic to increase antenna range.

A one person capsule is EXTREMELY cramped; I've seen plenty at space museums. Imagine sitting in a modern airline "cattle car" seat for 15 days and, no, you can't get up to go to the bathroom. IIRC, you get about 7-ish days of hab time/seat if you use the first capsules; If anything, @RoverDude is giving more hab time in those base parts than is realistic or historical. The simple solution is to fly faster. Burn a bit more fuel and get to Minmus in 2 or 3 days instead of 5 or 6 days; That doesn't require any new tech nodes. The Apollo missions had quite a bit more room to move around compared to the early manned missions. And they didn't spend more than 2 weeks in them.

I believe a double click in empty space deselects your target. I had Googled for how to eliminate clickthrough in KSP mods and it sounds quite painful. The official fix, being a programmer but not knowing KSP/Unity, is there is a new API and GUIs have to be rebuilt from scratch to cleanly eliminate clickthrough. There are hacks other mods have done but it sounds tricky to get it right. I end up slowing down how quickly I click on Precise Node to limit the number of time I have things like target deselect happen. I'm also constantly moving Precise Node GUI around to avoid conics of other vessels. I blame KSP/Unity for having such a crappy API for so long that hundreds of mods have clickthrough problems with no easy fix.

Dunno if there is any strong doco but here is a short version as I understand it: 3 types of efficiency losses are tracked/modeled: air drag, gravity drag, thrust vector drag Air drag is resistance from the air being pushed out of the way on a body with an atmosphere. Having nicely shaped rockets (pointy) helps here. Use fairings around your space payloads. Worst air drag is within 10 to 30 seconds of launch; you are moving fast and the atmosphere is thick. Gravity drag is the loss from being deep in a gravity well. For example the worse case is having thrust equal to your weight at the surface. You won't lift off but technically you are pressing down on the launchpad with the weight equivalent of a sheet of paper (ignoring the streaming hot gases beating on the pad); This would be 100% gravity drag loss. As you get further from the center of a body's mass (assuming you are trying to orbit), gravity drag goes toward zero. The perfect launch on an airless world is to get enough altitude to clear mountains then burn sideways until you achieve orbit. Atmospheres need to be cleared and this causes you to waste a lot on gravity drag. Thrust vector drag is the loss from having to point your rocket thrust in some other direction than prograde. This can't be zero unless you have a perfect launch that already starts at a "gravity turn" angle (10 to 20 degrees with a strong enough booster to not go sideways, think bottle rockets). A common place to generate a lot of this drag is a weak engine on an upper stage that is struggling to push you into orbit. Your thrust vector will be way off from prograde. The window also sums them all up for you. In general gravity drag is the biggest hitter. You can improve by increasing the angle. The tradeoff is that you then experience more air drag and potentially parts burning up from heating. A certain amount of thrust vector drag is unavoidable. You are trying to turn from straight vertical to horizontal. GravityTurn generally does a much better job on thrust vector drag then you manually launching rockets into space. My guess is that thrust vector savings are one of the biggest that users gain by automating launches.