Aelfhe1m

Example To change this part from MonoPropellant to LiquidFuel: PART { name = foo RESOURCE { name = MonoPropellant amount = 10 maxAmount = 10 } } Use this patch @PART[foo] { @RESOURCE[MonoPropellant] { @name = LiquidFuel } } NOTE: ModuleManager is case sensitive

Very shallow re-entries give much more time for heat to build up (and the capsule experiences less braking and stays faster longer as well). The amount of heat being generated at any given instant may be lower but the total amount of heat is greater. I generally use about 50-60km as a ballpark figure for re-entry pe.

Then use the kerbal.curseforge.com version instead of default Curse. Same content but no adverts or timers.

To expand on my previous reply. I took a look at the code and it doesn't compile in 1.3 as stands. I was able to edit it enough to get a basic compile but I haven't done any serious testing (only built a couple of parts in an MKS inflatable workshop) and I don't have a deep understanding of the mod to know where any pitfalls might be. I'm also hesitant to publish the modified code when the original author has been on the forum recently.

Haven't checked the figures but I am seeing them switch - tested in KSP 1.3 (with a lot of other mods installed)

Sounds like you're having a bad experience there. Anecdotally I've not been having any problems with Bon Voyage. The rover below has been to almost every biome on The Mun now and its big brother has traversed Kerbin from pole to pole and pretty high up the mountains too. I only had one terrain glitch problem when going to a polar Munar monolith and even then BV placed the rover upright on a stable patch of terrain even through surrounding terrain was severely messed up. It was also able to navigate away from that location although it wouldn't have been possible to drive out of there manually. Power wise the sunrise delay seems OK to me. Maybe a little conservative in how high the sun has to get before starting roving but not unreasonable and probably averages out for not parking the rover in an ideal angle/location to catch the earliest light. Edit: just for clarification the save discussed above is for KSP 1.3

Virus? You can also download both 0.6.3 and 1.0beta through the GitHub releases tab. GitHub link is at the bottom of the OP if you wish to avoid Curse.

Quick glance shows the following: to modify the amount of a resource the correct syntax is @RESOURCE[name] { @amount = <newamount> @maxAmount = <newmax> } Inconsistency between :FOR[KerbobulusSpaceProgram] and :FOR[Kerbobulus Space Program] - won't actually prevent anything here from working but it's best to stick with just one - and without spaces is easier since they need to be replaced by the wildcard ? to work properly in MM. In @PART[XOrionPodX|XOrionPodXbb31|//OrionDockingPort3a49capXx|OrionDockingPortXx|//OrionDockingPortXWSTANDARDDOCKPORT|XOrionLES]:FOR[Kerbobulus Space Program] the // marks the start of a comment and causes the rest of the line to be ignored @PART[xparachuteRadial2x/xparachuteRadialx] should use a vertical bar (|) not a slash (/) - also missing a closing brace (}). It could also be simplified using wildcard to @PART[xparachuteRadial*] (assuming there's only those two radial parachutes).

A minimum install of Heisenberg will look like the below image (you can have extra mods as well but must have at least these - in these locations): Also when your airship is launched it will initially have no buoyancy and will just sit on the runway. To get it to lift off open the HL Airships control panel by clicking on the AppLauncher button. Click the two radio buttons to turn altitude control and auto buoyancy on. Then give the "++" button a couple of taps and after a short delay you should rise gently into the air.

You might try Tweakable Everything - post doesn't say if it works on 1.3 (I haven't tested myself since it conflicts with TweakScale which I do use)

Can confirm this also happens with KSP 1.3, MKS 0.52.1 (latest constellation download with updated USI Tools 0.9.2) and JSIAdvTransparentPods 0.1.14 Also some of the MKS parts are showing transparency cutaways by default where they shouldn't (e.g. the Tundra agriculture modules). I'm working my way through the parts to compile a complete list. Done - see below The ag module can be patched to disable transparent pods by adding: Edit: so far most Tundra parts seem to have the unwanted transparency issue - probably because of the placeholder interiors being autodetected by jsi? Edit2: Finished checking all the USI parts. Duna and Ranger parts are OK (non-transparent). Otter cab has same issue as Karibou. Malemute, Honeybadger. AES, HERP and all passenger cabs have no issues (no transparencies).

Bluedog Design Bureau also has some hydrolox engines. Also SSTU includes some Az50/NTO engines and RCS.

Just tested this in my many mod game and looks good. The usual steps I was using to create a display glitch are no longer a problem.

Well, good news - bad news. The good is that in an isolated test build with just MechJeb and RCS BA I was unable to trigger the bug with either the new or previous DLLs. The bad news - in my MANY mod career game. The presence of RCS BA (either version) will trigger the bug but removing RCS BA fixes MechJeb. Not sure what's going on but it must be some sort of more complicated interaction with one of the other mods or memory usage or CPU load or ...

I think the problem is in the setupStyle class where RCS build aid is directly modifying GUI.skin.label and GUI.skin.toggle rather than working with copies. This can cause issues for other mods that assume the default skin values. Although I agree that perhaps MechJeb should be explicitly setting wrap rather than assuming the default.

Some general thoughts on the subject of reducing the number of individual textures needed for a full suit pack. Rather than have the entire texture replaced for every variant it would be nice to be able to specify a base texture and then apply "decals" to it (similar to flags on craft parts or the labels on some USI/WBI containers/parts but automatic based on trait/rank of kerbal) Similarly take a look at what SSTU are doing with recolourable templates on tanks and other parts. Something like this (again automatically applied via a config) could be used to change blocks of colour for different traits. Not sure how practical/difficult these would be although I imagine they would depend on being able to swap out the geometry of the Kerbal model. Although helmet replacement should at least be doable:

When launching from a non-equatorial location, the launch azimuth (direction of take off) and final intended inclination will not match. For Cape Canaveral a due east launch (at the right time of day) will put the vessel within about 0.25° of the Moon's orbital inclination (better if you do a slight dogleg on ascent). I haven't played RSS in 1.3 but the 1.2.2 version of RO has no problems with targeting a launch to plane of Moon from the Cape.

Yes, the Moon isn't in the plane of the ecliptic but neither are any of the planets. Venus is 3.4°, Mars 1.9° and Mercury 7° relative to the ecliptic. Of the outer planets Uranus is least inclined at only 0.8° and Saturn the most inclined at 2.5°. Launching to the Moon's orbital plane is easy to do by eye or with MechJeb and is a reasonable "eyeball approximation" of an initial parking orbit for an interplanetary transfer. (The pre-positioned satellite in the wiki link can also act as a launch target but requires editing orbital parameters either directly in your save file or with hyperedit). To work out what the ideal parking orbit is for any given transfer window (which may be nowhere near the ecliptic) requires solving for the specific orbital alignments at that time - best done with a tool like KSPTOT or by looking up mission parameters if you're recreating an actual mission.

The patch for the COT-250 is already part of MKS. I just modded the values slightly for the COT-125 - they would need to be checked for balance though.

@KSPrynk Here's an untested patch that should add the water -> LH2 + Ox convertor to the COT-125. I've made it less efficient/slower than COT-250 (I think):

The Moon's orbital plane is close enough to the ecliptic for most purposes.

The Tantares docking ports use the same nodeType as the Stock medium sized ports ("size1") while the CxA ports use a custom nodeType ("APAS_CXG"). In order for two docking ports to be compatible they must use the same nodeType. The Tantares ports are also gendered while the CxA ports aren't. You can make the Tantares ports compatible using this ModuleManager patch that will allow them to dock to both stock and CxA ports: @PART[Eridani_DockingMechanism_*] { @MODULE[ModuleDockingNode] { @nodeType = size1,APAS_CXG @gendered = false } }

@akron I just encountered a bug with the site survey camera. When a scientist on EVA tries to restore the camera through its PAW, there's an error shown saying a scientist is needed to reset it. After a bit of digging checking configs I eventually looked at the code for DMModuleScienceAnimateGeneric and the test for a scientist was inverted. I've put a pull request on @DMagic's GitHub that should fix it.

@garwel, @The-Doctor While we wait to see if @theSpeare will return, I took a quick look at this mod's code and it requires just a single line edit to get it to compile on 1.3. A quick test seemed to work fine as I was able to get a science spot and collect science from it. If anyone would like the DLL, I've uploaded it here. Just install the last version of RoverScience and replace the DLL in it's Gamedata folder with my one.

Also Gamma and Waxwing from SXT (UK's Black Arrow rocket). But really since you're talking alt-history you're going to have to invent a lot of stuff to fill the gaps in real history or substitute in real US/Russian designs.