Tonka Crash

You only need to ask once, For anyone to help you, we need a copy of the KSP.log and possilby the ModuleManager.ConfigCache for anyone to have a chance of helping you. Post them to Google drive, Dropbox or someplace similar and share a link here.

@Stone Blue I've submitted a PR with my changes. I've done quite a bit of testing, but probably missed something. I specifically tested the standard engines for launch aborts on the pad and various points on the way to orbit. If the engines aren't used for abort they have enough dV to get out of Kerbin orbit, but not much more with the built in Monoprop capacity. The capsule seems pretty stable on reentry without SAS starting from a slightly tumbling reentry. If CTT is installed the capsule is in the Heavy Command Modules node. Monoprop engine pods are in Specialized Control alongside vernier engines. LFO engines are in Precision Propulsion. I added an optional LFO variant of the engine pods, but with no built in fuel capacity. A separate fuel tank must be carried. Using the smallest stock 2.5m tank this gives the capsule plenty of dV for trips from Kerbin Orbit to the Mun or Minmus and back to a landing on Kerbin. Below is a trip to the Mun with LFO engines. 4 engines combined are the equivalent of a LV-909 Terrier. Makes for a nice compact Mun Taxi. I also added an Indicator Lights patch since I use this for all crewed modules. The shorty engine pod patch and LFO engines are in ArcAerospace/Patches/OptionalTweaks.cfg. They need to be uncommented to work.

I'm putting some of my changes that go beyond just balance updates in a OptionalTweaks.cfg patch file that will have this along with an LFO variant. The options will be commented out for distribution, so the user would have to uncomment them in the patch to enable them.

@Stone Blue I've got a few hours to do some testing and balance checks mainly aim at career. A big change will be cutting the amount of Monoprop onboard to more realistic levels. One other thing I'm doing (at least locally even if it doesn't make it into the mod) is to change the shape of the engine pods. It's a simple MM patch change. At first I just wanted a way to fit chutes in line with the engine pods without a lot of clipping, then I realized the shorter size made the engines work better with other command pods.

This sounds like a Pathfinder problem? What makes you think it's related to KAS?

@rmaine Try reverting to #957 and see if that works. I reported a similar problem with the Rendezvous Autopilot failing to automatically execute maneuver nodes. It looks like there were code changes around the automatic node execution in #958 that broke this function.

CTT - Community Tech Tree CRP - Community Resource Pack EL - Extraplanetary Launchpads EVS - Easy Vessel Switch EVE - Environmental Visual Enhancements IL - Indicator Lights KEI - Kerbal Environmental Institute KISS - Kerbal Improved Save System KPBS - Kerbal Planetary Base Systems USI - Umbra Space Industries USI-LS - Umbra Space Industries - Life Support I'm used to seeing B9PS or even just B9 instead of B9PSW. Usually just MJ is enough to refer to the current MechJeb 2. I don't think I've ever seen referred to as MJ2. I haven't been around long enough to ever have seen MechJeb 1.

@woetoe Before you start installing mods. Start with CKAN It's a separate program to make installing and updating mods easier. Many mods have dependencies and CKAN usually takes care of grabbing any required dependencies a mod may need without you needing to do a lot of research. Also take a look at this thread:

@Tokamak KAS does stand alone. No screwdriver required to connect KAS parts to other KAS parts. Even a pilot can handle this. Just right click on the part and grab the connector and drag it close enough to the part you want to attach it to and you should see "Attach Connector" in the PAW menu of the part.

We need a log to troubleshoot. It's probably installed in the wrong place or you are missing dependencies. I recommend using CKAN for installing mods

Read this

I've been using it mostly successfully in 1.9.1. The only issue I run into is that periodically the window resets to default sorting. All contracts are open and any mission sets are gone and hidden contracts are back on the main list. I gave up on mission sets as setting them up again is a nuisance. Usually I just hide contracts not actively waiting on me to do something like survey contracts just waiting out a number of days in orbit. I haven't noticed what circumstance triggers a reset and looking through this thread it's been a reported problem in the past, but hadn't been commented on in a couple years.

@adriangm44 I didn't see anything obvious about why the winch is staging. Are you manually extending and retracting the load before launch? I see where the which connector is misaligned and won't "dock". But it's not clear to me why it's doing this in the first place. It's not a behavior I see in game. I did find it pretty easy to get the connector to misalign extending and retracting the winch if the weight of the payload was resting on the winch. It's why you see arms in the my test craft below. I did a little experimentation and I think most of the problem is the robotic parts. First up I stuck a payload on a winch directly attached to the payload fairing. I could launch this load without the payload flopping around. The arms holding the payload don't do anything with the winch retracted since it's one vessel and parts can't collide with other parts of the same vessel. Once launched and falling through the atmosphere I extended and retracted the winch cable. Now I have two vessels and the arms helped align the payload as I retracted the payload so the winch connector would align with the winch body and connect. At that point the payload was again part of the vessel and didn't flop around. I even tried extending a little cable before launch so the arms would hold the payload in place. This looked good on the pad, but didn't work in flight. The arms didn't have enough strength to keep the payload from pushing them over with aero loads on everything. Next up I added a piston and hinge under the payload. The hinge was locked in the VAB. This created all kinds of problems. There have been reports stock robotic parts do not respect the lock status when staging. That's the behavior I saw. Once I stage the hinge under the payload would flop over even though the hinge said it was locked. Again the support arms didn't do anything since parts can't collide with other parts of the same vessel. Setting the payload to Autostrut Heaviest Part did help get the thing flying. But side loads would still cause the payload to flop over on the hinge under the winch. I see you have a heavily modded install including Infernal Robotics which I've never used it and don't know how it affects things. It's one reason I tried testing with a simpler design. You may just be running into the limitations of KSP physics with a craft that can't work as it is. I'd look at trying to design something so robotic parts and the winch aren't carrying launch loads. As a shot in the dark I braced the payload with struts. And it worked like a charm. The struts held everything rigid through launch. As soon as I extended the winch cable a little, the struts disappeared as if they had been staged. If you can, I'd give this a try. If you need them reusable try the TJ-1 struts in KAS or my extended length ones.

Yes. To debug your issue it's useful to capture any errors around when the problem occurs.

Mun Station Shipyard is finally fully operational

Using CLS you have to be careful with surface attached connections. The structural nodes your docking ports are connected to on the central station are probably surface attached and not allowing Kerbals to pass. Typically you have to manually allow surface attachments to be passable in the VAB. After launch I've had to edit my save file by hand to fix this when I've forgotten. You have to first find you vessel in the save, then the problem parts and reset a logical from false to true, but make a copy of your save file before you attempt this. While CLS was in limbo before being adopted in March I gave up on it. It's good for forcing you to think logically about how your Kerbals would move through a vessels, but it is kind of a nuisance to deal with all its quirks. After not having a working version for a while I found I didn't miss the little hassles like forgetting to enable a suface attachments between two otherwise passable parts and always needing to open docking ports. I still design stations as if I had CLS installed but don't think I'll ever use it again.

You're expecting the maintainers to always keep things current in a timely manner. It's been 3 months since 1.9.1 release and 45 of the 118 mods I use haven't been updated from 1.8. None of them need an update to work but they report as out of date. At least leaving it open ended requires no interaction at a later date if its still working. There are no guarantees a mod works even in the version it was compiled for. I've had a PR in for a mod on github for over a year for a pretty subtle bug I found and fixed. The maintainer has yet to patch it, so I've been compiling it locally since 1.6.1. For most mods it's pretty apparent when they really break and maintainers seem more interested in fixing actual problems if they haven't burnt out on idiot questions. In either case users are left with trying the latest release compatible or not. Not really, when a mod update is released CKAN that over laps an existing range the newest is typical found as compatible with your version. KAS dealt with this in the 1.7.x releases. 1.7 and 1.7.1 were both mod breaking. Each fixed KAS version released was compatible up to 1.7.99. But install 1.7, 1.7.1 or 1.7.2 and it will find the appropriate version. I recommend people use CKAN, because it really is trivially easy to keep patches current and takes very little time. At the same time you are asking the impossible, expecting everyone to understand how their tools work. My feeling is too many people using mods have no business operating a computer, I'm surprised they even find KSP fun with it's complexity. Many seem mentally incapable of handling a manual install and or even using the forum search function, but they are fellow players and some of us try to help them out. I've seen one case like you describe and it was due to bad CKAN metadata. I don't remember the specifics, but it was along the lines of release 1 for 1.6.1 with no upper limit and then release 2 for 1.7.1-1.7.999. Trying to install for 1.8 grabbed the 1.6 version. Once the problem was identified a message to the CKAN guys got it cleared up. No changes to the mod itself had to happen.

Doing things this way was to avoid updating just for a version change that has zero impact on the compatibility of the mod. This mod had not updated to 1.9+ because it still worked fine and there were no new features to be added. But it created problems for CKAN users. CKAN would consider any mod that had CCK as a dependency incompatible with anything higher than 1.8.9 just because CCK's metadata didn't have 1.9+ listed as compatible. I know how to work around that and it was never an issue to me, but a lot of less experienced CKAN users were having issues finding mods on CKAN that the forum threads said were current for 1.9.1. For those of us that actually try to help newbies with their installation problems, it gets old telling users "yes a mod for 1.8 still works in 1.9.1 and here's how you change your CKAN settings to allow it". It's simpler to just leave the max version open ended and fix real problems when they need fixing rather force mod makers to push an update just because KSP updated.

Can you explain what prompted this change? Do you anticipate changing it again? I'm trying to debug some problems with Indicator Lights that disappeared and textures that changed after updating ReStock when everything was working like I intended before the update. Edit: Found my problem. I had some personal patches to make things work that relied on BEFORE[ReStock] that now needed BEFORE[000_ReStock]

@zer0Kerbal Just wanted to say I'm loving this mod. Good work keeping it going. Here I've got an Engineer servicing my Ore hauler with my Mun mine in the background. he lander brings down USI supplies for the miners and takes back up Ore or MetalOre. I have small containers for each resource produced by the mine attached to the pad. I use KAS to transfer resources from the pad to the lander and Simple Logistics keep the pad's containers topped up as I transfer them to the transport. I found working through KAS for the final step allowed finer control. TI'm still using the release available through CKAN.

I'll probably buy the game at launch, but won't play much until mods patch holes. To me the functionality provided by KIS/KAS & KER are essential. Without them, I don't really care how what else they've added to the game. For me KSP didn't become addictive until EVA became useful with KIS and KAS. I'll also want some way to customize the info displayed to me in game. Without these features I'll stay with the original.

The style of the UI doesn't really matter much to me. I can adapt to a different look. What I think is a huge mistake is moving all the flight instruments to the bottom left corner. These should be front and center not shove off to the side. The Orientation Controller is a waste of space and redundant information to the Navball, unless it's supposed to replace the SAS controls. Where are the maneuver node and target controls? Kerbal portraits are not that important to me, ever. Leave them in a corner. Same with the time warp indicator. It's not critical to the task of flying. If you are going to "fix" the Kerbal portraits, figure out a system to make find a specific Kerbal out of a group of 40 on a ship easy. A pause button was a needed control? Hitting the 'esc' key has always been fine in most games I play. I started KSP on the Xbox and hated the UI. Tried it on the PC and liked it enough to buy my first PC for gaming in a decade. I kind of wonder if the guys designing and approving the KSP2 UI ever played this game with anything other than MechJeb in the sandbox. If the UI turns out to be a mess, I doubt I'll spend much time in KSP2. The Adventure mode sounds like a step in the wrong direction to replace contracts. I tend to play each of my games with the same loose goals, but contracts add a randomness to how each of my games evolve over time. Early career when cash is restricted tends to force me to be more efficient and try things I'd otherwise skip, like airplanes. It Contracts is a huge improvement to me over Science mode. The Adventure mode sounds like it's going to just be a series of check boxes to accomplish the next "first" on a preprogrammed progression to the next "first". Where's the randomness that make replays feel fresh?

To all users of this mod. I installed this and TweakScale warnings and errors exploded in my log. I tracked it down do a patch [snip] CST-100 Starliner\Patches\All Tweak\All Tweak.cfg. @PART[*]:HAS[!MODULE[TweakScale]]:FINAL { %MODULE[TweakScale] { %name = TweakScale %type = stack } } This [snip] is throwing a TweakScale patch on every part without TweakScale already defined. I have a good number of parts where it isn't defined and shouldn't be to avoid documented problems in TweakScale and for parts I don't want to rescale. To top it off you have it run with the :FINAL keyword which is about as poor form as you can do with a patch for a mod. @VoidCosmos You should either delete this patch entirely or take the time to explicitly define proper TweakScale settings for only the parts in this mod. Don't throw a @PART[*] patch at users that will create problems for other mods. You should also use :FOR instead of FINAL so other users can properly address :AFTER, :BEFORE and :FINAL patches around the behavior in this mod.

Without contracts how do you get tourists?

The engineers at my Mun mining site finally got their landing pad finished. First landing of the ore shuttle for supply to the orbital shipyard.