Tonka Crash

Is there a syntax to prevent patches from being applied to a mod without modifying each foreign mod? I'm looking at the KOOSE pods and it's silly the number of toggles that are in the right click menu of the parts. I'm running about 70 mods and a good number of these are applying patches to the KOOSE parts that aren't really relevant to an escape pod. I'd like to be able to put together a patch in the KOOSE mod to tell other mods to skip it. The best I can come up with is deleting modules after they've been applied as part of a set of :FINAL patches in my personal mods.

Look for the README.TXT installed in the GameData\ConnectedLivingSpace\Configs directory. It explains how to enable a lot of stock parts that aren't recognized by default. Anything not in those files you have to patch yourself.

@IgorZ Laie does remind me of an issue I've run into a couple times. It would be nice to be able to cut loose items in a Kerbal's personal inventory when there isn't anything around. I've had a few cases where I've had a Kerbal on zero-g EVA pick up an SC-62 and during the attachment to the kerbal something collides that sends the Kerbal spinning off into space. When the container is near the 1-ton limit the weight makes it very difficult to recover and fly back to the station. It would be nice to be able shed the load. I run about 50/50 being able to get back vs mounting a rescue to retrieve the lost Kerbal.

Test an air breathing turboprop engine from the Mk2 Expansion mod in orbit around Minmus was the dumbest thing I've seen.

Rados, Leevis and Bartrie landed on the Mun's South Pole to pick up a surface sample for analysis at the Mun Orbital Research Station.

EDIT to add: Aren't the chutes there from the start? I don't know why you would delay their availability. They are safety equipment that any Kerbonaut should have some familiarity before they ever leave the ground. IRL, I've had to go through egress training to show I could strap on a chute and knew how to pull the release even though I haven't jumped out of a plane in 20 years. In the game I've used them for a case where I didn't have enough chutes for a successful lander can touchdown so once the chutes I had deployed, everyone bailed out.

@infinite_monkey You need to leave the Squad and Squad Expansion (if you have the Making History DLC) directories for the basic game. These contain all the stock game assets. Next you'll need to keep any mods required to test your problem. I usually strip GameData down to just the Squad directories and use CKAN to add back in the mods causing problems to make sure I capture any dependencies.

@IgorZ Thanks for looking into this. I do have a feature request. Could the legacy ground pylon migrate to this KAS 1.0? I don't think it needs any changes, but I would hate to lose it as a part when the legacy items go away. Currently it's the only legacy part I use. Mainly as a distribution point to extend the reach of RTS-1 connections around bases. The KIS concrete base could replace it in a pinch, but the KAS part is better looking when you don't have parts stacked on it.

@Cheesecake I'm running a locally compiled version of 801 with a couple changes to the landing autopilot, but the only time I've seen something similar is if I have a second probe core or command pod at an odd orientation that is in command when I move it to the launch pad. Have you tried just a command pod with the AR202 on the side to see which way it thinks is up?

@IgorZ I did some testing in zero-g. I went to retrieve an adrift fuel tank from an old booster. I sent an engineer out and stripped all the parts from the tank, so I was only dealing with the one part. The tank had autostrut grandparent set from when it was launched. The ship with the RTS-1 had no autostruts enabled anywhere. When I connected the RTS-1 and turned the connection to docked, the autostrut jumped to the RTS-1 and the tank was rigidly fixed relative to my ship. Rotating my ship rotated the tank with it. Turning autostruts off on the tank and I could maneuver relative to the tank and the RTS-1 changed length as needed. I know the Dock Rotate mod does something to turn off autostruts across docking ports when its rotation mode is enabled on a docking port. My thought is the RTS-1 should do something similar when it's connected.

Thanks for the correction, my apologies to @Burning Kan

@Burning Kan That's really bad advice, deleting things without understanding what it may impact is a good way to break the game. Module Manager is required to apply patches, so deleting it will break the game. Did you mean the ModuleManager.ConfigCache? Even that gets replaces when MM detects a change in the patches. @HappyKerbatron Try the following. Since TechRequired and entryCost already exist for the parts, you need @ before for them to tell module manager to replace the existing values. This is assuming you are doing this through a patch file of your own. The alternative is to just edit the part.cfg file in GameData\MechJeb2\Parts\MechJeb2_AR202. BUT, I don't recommend that as updates to MechJeb would overwrite your changes. @PART[mumech_MJ2_AR202] { @TechRequired = flightControl @entryCost = 15000 @MODULE[MechJebCore] { @MechJebModuleCustomWindowEditor { unlockTechs = flightControl } @MechJebModuleSmartASS { unlockTechs = flightControl } @MechJebModuleManeuverPlanner { unlockTechs = flightControl } @MechJebModuleNodeEditor { unlockTechs = flightControl } @MechJebModuleTranslatron { unlockTechs = flightControl } @MechJebModuleWarpHelper { unlockTechs = flightControl } @MechJebModuleAttitudeAdjustment { unlockTechs = flightControl } @MechJebModuleThrustWindow { unlockTechs = flightControl } @MechJebModuleRCSBalancerWindow { unlockTechs = flightControl } @MechJebModuleRoverWindow { unlockTechs = flightControl } @MechJebModuleAscentGuidance { unlockTechs = flightControl } @MechJebModuleLandingGuidance { unlockTechs = flightControl } @MechJebModuleSpaceplaneGuidance { unlockTechs = flightControl } @MechJebModuleDockingGuidance { unlockTechs = flightControl } @MechJebModuleRendezvousAutopilotWindow { unlockTechs = flightControl } @MechJebModuleRendezvousGuidance { unlockTechs = flightControl } } } @PART[mumech_MJ2_AR202_features1] { @TechRequired = flightControl @entryCost = 30000 @MODULE[MechJebCore] { @MechJebModuleCustomWindowEditor { unlockTechs = flightControl } @MechJebModuleSmartASS { unlockTechs = flightControl } @MechJebModuleManeuverPlanner { unlockTechs = flightControl } @MechJebModuleNodeEditor { unlockTechs = flightControl } @MechJebModuleTranslatron { unlockTechs = flightControl } @MechJebModuleWarpHelper { unlockTechs = flightControl } @MechJebModuleAttitudeAdjustment { unlockTechs = flightControl } @MechJebModuleThrustWindow { unlockTechs = flightControl } @MechJebModuleRCSBalancerWindow { unlockTechs = flightControl } @MechJebModuleRoverWindow { unlockTechs = flightControl } @MechJebModuleAscentGuidance { unlockTechs = flightControl } @MechJebModuleLandingGuidance { unlockTechs = flightControl } @MechJebModuleSpaceplaneGuidance { unlockTechs = flightControl } @MechJebModuleDockingGuidance { unlockTechs = flightControl } @MechJebModuleRendezvousAutopilotWindow { unlockTechs = flightControl } @MechJebModuleRendezvousGuidance { unlockTechs = flightControl } } } @PART[mumech_MJ2_AR202_features2] { @TechRequired = flightControl @entryCost = 100000 @MODULE[MechJebCore] { @MechJebModuleCustomWindowEditor { unlockTechs = flightControl } @MechJebModuleSmartASS { unlockTechs = flightControl } @MechJebModuleManeuverPlanner { unlockTechs = flightControl } @MechJebModuleNodeEditor { unlockTechs = flightControl } @MechJebModuleTranslatron { unlockTechs = flightControl } @MechJebModuleWarpHelper { unlockTechs = flightControl } @MechJebModuleAttitudeAdjustment { unlockTechs = flightControl } @MechJebModuleThrustWindow { unlockTechs = flightControl } @MechJebModuleRCSBalancerWindow { unlockTechs = flightControl } @MechJebModuleRoverWindow { unlockTechs = flightControl } @MechJebModuleAscentGuidance { unlockTechs = flightControl } @MechJebModuleLandingGuidance { unlockTechs = flightControl } @MechJebModuleSpaceplaneGuidance { unlockTechs = flightControl } @MechJebModuleDockingGuidance { unlockTechs = flightControl } @MechJebModuleRendezvousAutopilotWindow { unlockTechs = flightControl } @MechJebModuleRendezvousGuidance { unlockTechs = flightControl } } } @PART[mumech_MJ2_AR202_features3] { @TechRequired = flightControl @entryCost = 100000 @MODULE[MechJebCore] { @MechJebModuleCustomWindowEditor { unlockTechs = flightControl } @MechJebModuleSmartASS { unlockTechs = flightControl } @MechJebModuleManeuverPlanner { unlockTechs = flightControl } @MechJebModuleNodeEditor { unlockTechs = flightControl } @MechJebModuleTranslatron { unlockTechs = flightControl } @MechJebModuleWarpHelper { unlockTechs = flightControl } @MechJebModuleAttitudeAdjustment { unlockTechs = flightControl } @MechJebModuleThrustWindow { unlockTechs = flightControl } @MechJebModuleRCSBalancerWindow { unlockTechs = flightControl } @MechJebModuleRoverWindow { unlockTechs = flightControl } @MechJebModuleAscentGuidance { unlockTechs = flightControl } @MechJebModuleLandingGuidance { unlockTechs = flightControl } @MechJebModuleSpaceplaneGuidance { unlockTechs = flightControl } @MechJebModuleDockingGuidance { unlockTechs = flightControl } @MechJebModuleRendezvousAutopilotWindow { unlockTechs = flightControl } @MechJebModuleRendezvousGuidance { unlockTechs = flightControl } } } @PART[mumech_MJ2_AR202_features4] { @TechRequired = flightControl @entryCost = 183335 @MODULE[MechJebCore] { @MechJebModuleCustomWindowEditor { unlockTechs = flightControl } @MechJebModuleSmartASS { unlockTechs = flightControl } @MechJebModuleManeuverPlanner { unlockTechs = flightControl } @MechJebModuleNodeEditor { unlockTechs = flightControl } @MechJebModuleTranslatron { unlockTechs = flightControl } @MechJebModuleWarpHelper { unlockTechs = flightControl } @MechJebModuleAttitudeAdjustment { unlockTechs = flightControl } @MechJebModuleThrustWindow { unlockTechs = flightControl } @MechJebModuleRCSBalancerWindow { unlockTechs = flightControl } @MechJebModuleRoverWindow { unlockTechs = flightControl } @MechJebModuleAscentGuidance { unlockTechs = flightControl } @MechJebModuleLandingGuidance { unlockTechs = flightControl } @MechJebModuleSpaceplaneGuidance { unlockTechs = flightControl } @MechJebModuleDockingGuidance { unlockTechs = flightControl } @MechJebModuleRendezvousAutopilotWindow { unlockTechs = flightControl } @MechJebModuleRendezvousGuidance { unlockTechs = flightControl } } }

I'd fully expect using Jr. ports instead of Sr ports on 2.5m diameter parts would work without trying it a sandbox. What I don't know and hope @RoverDude can answer is if there are any hidden gotchas to this approach that may not be obvious. Like is the resulting connection strength a function of the docking port size? Doing this in a sandbox may not show some of this.

University of Kansas, BS Aerospace Engineering, 1991.

@RoverDude Does size matter? I'm asking for a friend. This is about docking ports. Since the ports are going to disappear when compressed, besides aesthetics, does it matter which size is used for the joint? I know both sides of a connection need the same size, but is there any reason not to just use Jr. ports everywhere? I have a friend that just started using Konstruction and the question came up when talking about using KIS/KAS to replace a bunch of conventional docking port joints on his space station. It's more convenient to just use Jr. ports everywhere, since more fit will fit in a KIS Inventory for shipment to the station.

I finally got my Minmus station online. It was assembled in LKO over 11 launches and then moved to Minmus in this form. The plan is to serve as a fuel depot for interplanetary missions. At present the fuel tanks are mostly empty. A mining site has been set up on Minmus, but the big drills are still en-route. For now it's getting by on a pair of Jr. drills on the back of the exploratory rover.

You can also unlock it through a patch file to have it appear in the editor all the time. // Unhide deprecated part(s) @PART[Mark1-2Pod]:FINAL // Old 3 man pod with worse stats than current pod { @TechHidden = False @category = Pods }

@Burning Kan I use TAC Fuel Balancer to transfer resources and I haven't had problems transferring over a RTS-1 connected while docked. I've only used the KAS GUI undocked since that's the only way to transfer resources undocked. @IgorZ Autostruts are my problem. I have a base on Minmus. I deployed it for a contract before I had some of the tech nodes unlocked that I would have preferred, so it's underpowered for night time. I sent up a mining rover for a later mining contract that has a nuclear reactor on board that can power everything through the night for decades. So, I figure I'll just connect up the RTS-1 between the base and rover and that will solve my power problems. This is when I ran into docked mode locking the two vessels together. This was also the first time I'd tried using the RTS-1 in docked mode, so I thought it just behaved this way which prompted my previous post, my apologies for not realizing it was supposed to behave differently. 1st Screenshot in UNDOCKED mode: Autostruts shown from the debug menu. Squad has wheels set to Autostrut to Heaviest Part and it's locked so the user can't change it. Those are the only autostruts in use on any of the parts. 2nd Screenshot in DOCKED Mode: The autostruts have shifted to link the wheels of my rover to the base and that's my problem, not the RTS-1. To test this further I set up the light pole to the far left. It was not attached to the surface and the RTS-1 was set to docked so it has power running to it. I was able to kick it around like a soccer ball with a Kerbal and the RTS-1 accommodated the motion like you said it should and the lights stayed on. To me this is a problem with the default game behavior and not anything specific to the KAS parts. The other case where I've run into the KAS parts appearing to lock positions was in zero-g. Occasionally I'll send a ship out to retrieve spent boosters that still have some LFO in them and bring those back to the space station and transfer the fuel to the station. I intentionally use autostruts frequently on booster stages and on the space station, so I think the autostruts are jumping across the vessels when I switched to docked mode to use TAC Fuel Balancer to transfer resources. I still need to test this the next time I do go retrieve a fuel tank.

@IgorZ Thanks for the response, I'll start investigating.

@IgorZ I would like to use the RTS-1 as an extension cord to maintain a persistent electrical connection between components on a base. I specifically do not want to deal with EC transfer with the gui. An example use case is stringing up light poles around my base away from structures.To do this the RTS-1 has to be in docked mode. Docked the connection behaves like the old KAS pipes with the RTS-1 exerting physics reactions on connected items. This seems to exacerbate the ground bouncing problem as the connected base spreads over a larger area. Is it possible to remove the physics in the connection while docked? Or, allow EC transfer while undocked without the gui? Ideally the RTS-1 connection would grow, shrink or rotate as necessary to allow independent motion between connected parts. This would more closely mimic a spring loaded hose real connection. As a minimum RTS-1 docked connections should behave like the TJ-2 link to at least give some degree of freedom at the connection points. The closest I can come is to run a TJ-2 link from a build to a ground pylon and connect the ground pylons with RTS-1 hoses. With everything in docked mode this gives a persistent power connection with some freedom of motion between connected parts, it's just really cluttered and uses a lot more parts than it should.

@Jan Irace Squad updated the models on several old parts. The current equivalent is Rockomax-64. It's stats are the same as the Jumbo 64. It has variant color schemes with one being orange. In the VAB right click the tank and at the bottom you have color choices. Everything "missing" just has it's parts category set to none so it doesn't appear in the VAB and techhidden = true, so it doesn't appear in the R&D nodes. These can be patched to return them, but it's really just creating duplicate parts. The only deprecated part that has different stats is the Mk1-2 pod that is inferior to the current Mk1-3 pod. I enabled it in my career at a earlier tech level than the Mk1-3 pod, but have only used it once or twice.

Googling for some real world comparisons Offroading winch rope is 50' (15m) commonly, but I also found a 95' (30m) heavy duty length. Having owned a couple winches I've never seen one on a Jeep that could hold the 95' length. These have fittings on the ends, so this isn't just cut to fit. Aerial Refueling Hose length is 15-20m. That hose is fat and there isn't much room for more in a refueling pod. Glider tow ropes look to be around 200' (60m), but I found a place selling spools up to 1500' (450m)

I installed Forza 7 on my PC and tried the XBox One controller, no problems. I haven't tried AFBW, but I might try it this weekend when I have time. I did another search of my computer and still don't have any more xinput files installed. I'm not complaining, as I'm not having any problems. I just offer this up for comparison to your system. My relatively clean system doesn't have problems and doesn't have numerous versions of the xinput dll. Your dll problem may be that KSP is actually finding a xinput1_3.dll when it should fail and fall over to using XInput9_1_0.dll. If your solution is working for you, great, but it may not be the best solution.

Just for a point of comparison, my computer is a 2 month old clean install of Windows 10 Pro 1803 with KSP as the only game ever installed by direct download from Squad, Steam has never been installed. Searching the hard drive the only result for xinput1_3.dll is the one in the KSP_x64\Plugins directory. No other exist on my computer. In my output_log.txt there is a line: XInput1_3.dll not found. Trying XInput9_1_0.dll instead... Searching for Xinput9_1_0.dll I get : C:\Windows\System32\XInput9_1_0.dll C:\Windows\SysWOW64\XInput9_1_0.dll C:\Windows\WinSxS\amd64_microsoft-windows-directx-xinput_31bf3856ad364e35_10.0.17134.1_none_18785281a71ced90\XInput9_1_0.dll C:\Windows\WinSxS\x86_microsoft-windows-directx-xinput_31bf3856ad364e35_10.0.17134.1_none_bc59b6fdeebf7c5a\XInput9_1_0.dll

@eberkain I use a KOOSE Nest for career rescue missions. Instead of launching new rockets for each rescue mission, I have a ship docked at the station to go retrieve lost Kerbals and bring them back to the station. The escape pods do the final leg of getting them back to the surface. When the Nest is empty I cut it loose, and ship up a full one.