Tonka Crash

I ran into a bug or maybe it's a known issue. I searched, but couldn't find mention of it. It doesn't seem like the location of items in a KIS inventory are tracked in the VAB. I had a contract for a 5 man base on Minmus with a greenhouse. I built what's shown below (minus the highlighted KIS container). There is a Planetary Base System KIS storage tank between the green house on the far right and the cupola. I filled it with items to be added to the exterior once on the ground, but putting items in the KIS container does not show changes in the center of mass. It became obvious, when I fired up engines around Minmus and started to cartwheel because the actual center of mass was about two meters to the right of the thrust line even though I'd balanced the thrust through the CoM while assembling the base. I got it down by tweaking the thrust limiters of each engine to balance everything, but it would be simpler if the CoM marker in the editor reflected the actual CoM. I tested that it wasn't just the KPBS part by adding the ISC-6K container (highlighted below) and filling it with KAS ground pylons. KER shows the mass go up and down as items are added or deleted, but the center of mass marker never moves, once in flight it's obviously different. Imugur link if embed doesn't work.

Here's my view of CAKN filtered the same way. https://imgur.com/tGL7UoX Looking at your CKAN screenshot, you still have crud from trying to manually install the mods preventing CKAN from installing them. Konstruction shows with an AD instead of checkbox because CKAN knows it didn't install it. I think this may be why MKS doesn't have a checkbox either. I would close CKAN and KSP and then scrub the GamaData tree of any of the mods you tried to manually install and only use CKAN to install them.

I was reading back through this thread and saw several comments on changing colors on shrouds. Decoupler Shrouds has this functionality. It also deals with shrouds around engines that don't match the stack size which is why I got it, but use it more than default engine shrouds to match the rest of the stack. It's also simple to add new textures, drop your texture into the textures directory and update ShroudTexturesConfig.cfg file in the same directory and they are added to the list of possibilities. I didn't know anything about textures before today, but was familiar with GIMP. Using info from this non-KSP thread I was able to create color matches to the gray and orange in the Missing History pack in about an hour.

I shows up as USI Kolonization Systems (MKS/OKS) or just filter the list by author RoverDude to find all the USI mods.

@DMagic Thanks for the quick update.

I'm reverting to the previous version. The biggest problem is that the conditions in a contract are not showing green as they are completed. (Did I actually hit the right orbit or not?) (Which tourists still need a ride down to the Mun's surface?) I verified this one with a friend on his game this morning and he sees the same behaviour. This is a mod killer, without it, this mod isn't useful and the reason I'm reverting. The Contract Window also initialized offscreen in most scenes, but this seems to be a one time nuisance. I had to exit and fix it in the persistence file. It would nice if this were in an external file that could be reread while running, or at least have them reset if you do a reset within the mod. I swap between a 1080p monitor at work (I don't have a lot to do at work lately) and a 4K at home, I've seen this before if I leave a window where it would be offscreen on the 1080p monitor, but I ran into this on the 4K monitor and I didn't think that was possible. Occasionally I'm seeing the contract window remain empty when I've changed scenes, e.g. from tracking station to flight, switch focus to a different ship. Once I click on the Contract Window it populates. On a positive note, I'm not seeing the InvalidCastExceptions or any errors for that matter from this mod or it's dependencies. Log File I didn't see anything obvious in the log. To create it I loaded the game went into the tracking station and switched to a satellite on a long term contract. Search for "Little Bro Recon". Then exit to main and quit. The Contract Window was open when I got to flight mode showing the contract for the satellite, none of the previously completed conditions were green. (Proper orbit, required equipment, required observations) Edit to add: I updated off CKAN last night, my friend this morning using CKAN

I noticed pretty much since I installed Contract Window+ a couple months ago that the ProgressParser dependency spams the logs with InvalidCastExceptions. I'm on Windows 10, KSP 1.4.5 (but this happened in 1.4.3 & 1.4.4) CKAN tells me I'm current before starting this afternoon. [WRN 14:42:10.721] [Progress Tracking Parser] Error In Finding Progress Node [PointOfInterest] Vessel Reference System.InvalidCastException: Cannot cast from source type to destination type.^M at ProgressParser.progressParser.vesselFromNode (.ProgressNode n) [0x00000] in <filename unknown>:0 ^M Link to output_log.txt

I got around to figuring out how to keep MechJeb from pumping all the monopropellant overboard on landings. I downloaded Visual Studio and managed to recompile MechJeb locally and started tweeking it to better behave for me.

I'd rather not, I don't use REKT, and I had a need for this one. I did this through trial and error constantly reloading the MM database to dial in the geometry. It took much longer than I expected and this was only one part, REKT has a lot more.

I've written a patch to add Indicator Lights to the pod to show if the pod is occupied. This adds 4 lights around the base of the KOOSE pod that stick out enough to be visible while docked in the Nest. You can take and use it however you want, or not, it doesn't matter to me. // KOOSE escape pod // @PART[KooSEpod]:NEEDS[IndicatorLights]:AFTER[KOOSE] { MODEL { model = KOOSE/Assets/Pod } // 4 lights equally spaced around base MODEL { model = IndicatorLights/Meshes/squareLamp scale = 1, 0.15, 1.2 position = 0.57, 0.0, 0.0 rotation = -32, 90, 0 } MODEL { model = IndicatorLights/Meshes/squareLamp scale = 1, 0.15, 1.2 position = -0.57, 0.0, 0.0 rotation = -32, 270, 0 } MODEL { model = IndicatorLights/Meshes/squareLamp scale = 1, 0.15, 1.2 position = 0.0, 0.0, 0.57 rotation = -32, 0, 0 } MODEL { model = IndicatorLights/Meshes/squareLamp scale = 1, 0.15, 1.2 position = 0.0, 0.0, -0.57 rotation = -32, 180, 0 } // Lights are controllable MODULE { name = ModuleControllableEmissive target = IndicatorLights/Meshes/squareLamp emissiveName = indicator } // Controlled by Crew Indcator (Pod Occupied or not) MODULE { name = ModuleCrewIndicatorToggle toggleName = indicatorToggle } MODULE { name = ModuleCrewIndicator emissiveName = indicator toggleName = indicatorToggle } } In the screenshot below, the top and the left nested pod are occupied. The nested pod on the right is unoccupied. If you haven't used Indicator Lights before the light color is controlled by the Kerbal's specialization: green for engineer, blue for scientist, and orange for pilot by default. The colors are set in a config file within Indicator Lights

Is Tweakscale one of your mods? KIS disables stacking if Tweakscale is present.

One thing I've been doing lately is disable thr roll axis control on tail fins and let them only react in pitch and yaw. Roll is handled by reaction wheels.

You know Wikipedia might be a better source for general info questions not related to the game. But to answer why complex stator turbine sysytemes are used is due to engine fuel efficiency. The higher the compression ratio, the higher the fuel efficiency. A single centrifugal stage (no one calls it an impeller in jet engines) can't compare to a multistage axial compressor for overall compression ratio.

Last week I finished a contract to put a station in orbit around Kerbin. I had attached a KOOSE Nest so I could drop off rescued Kerbals at the station instead of always spending money on new launches to recover rescued Kerbals to the surface. Caesar sits around in orbit maintaining the station and waiting for the rescue call, when the Nest is empty, cut it loose and orbit a fully loaded one. I finally had a got a Kerbin orbit rescue after a week of retrieving lost engineers around the Mun. Everything worked as planned, but I did run into a few items that could make it easier to use. I'm sorry if these have been mentioned before: In the right click menu of the Nest you have six decouple switches, but I have no idea which switch corresponds to which pod. Being a symmetric part I don't know if it's even docked in the orientation I assembled it in the VAB. Maybe have a number assigned to each switch that's painted on the mesh next to each pod. I ended up mousing around to get the right click menu of the pods to use the decouple node switch on the pod instead of trying to do it on from the Nest. I don't know if localization matters here. I use the Indicator Lights mod. I've come to rely on it to figure out where Kerbals are hiding in my stations. It would be nice if there were a light either on the Nest,on the reentry heat shield or at least visible from outside the Nest to show which pods are occupied. After I transferred the Kerbal and rotated the camera to figure how to decouple her pod, I got confused over which one I put her in. Even then I quicksaved, decoupled, and made sure I had her in the pod that came out before reentry. I play with Connected Living Spaces and I could not move a Kerbal into the pods without turning on the option for unrestricted crew transfers. I'd already fixed the Nest to be passable, but the problem seemed to be the hatches. The right click menu shows a Hatch status: Closed, but I have no switch to open it. I think with open hatches on both the Nest and the Pods they should be passable, but a closed hatch anywhere isolates the pod from being able to transfer crews. To be honest I still haven't downloaded the patch file you linked to earlier, maybe this is solved by that, or it could be another mod conflicting. After that everything worked as expected and I plan to keep using this.

RoverDude, I've been using USI-LS almost since I bought KSP a couple months ago. I ran across some odd part definitions when building a space station where some of your parts didn't allow surface attachments and some of the nodes seemed a little off. I've patched it for my game, but below is the set of patches if you feel like including them in an update at some point. I'm don't know what the convention is for submitting a change like this, so I'm including it here. // // Fix USI LS Parts to better match stock parts attachment rules. By default // none of these allowed surface attachment of other parts to them. // @PART[USILS_Greenhouse_Inline]:FINAL { @attachRules = 1,0,1,1,0 // only node attachment } // Adjust bottom node to be at bottom of part @PART[USILS_Greenhouse_MiniCupola,USILS_SmCupola]:FINAL { @attachRules = 1,1,1,1,0 // can be surface attached @node_stack_bottom = 0.0, -.15, 0.0, 0.0, -1.0, 0.0, 1 } // Add top node similar to standard Cupola. @PART[USILS_Greenhouse_Cupola]:FINAL { @attachRules = 1,0,1,1,0 // only node attachment node_stack_top = 0.0, 1.00, 0.0, 0.0, 1.0, 0.0, 1 } // Add top node similar to standard Cupola. // Adjust nodes to be at edges of part @PART[USILS_ViewingCupola]:FINAL { @attachRules = 1,1,1,1,0 // node and surface attachment node_stack_top = 0.0, 0.70, 0.0, 0.0, 1.0, 0.0, 1 @node_stack_bottom = 0.0, -.10, 0.0, 0.0, -1.0, 0.0, 1 }

It's not Squad's fault that mod makers put out parts without hatches, so why should it be their responsibility to fix a problem they didn't create? The worst offender in my game is the very popular USI Life Support with it's viewing cupola. It holds one Kerbal counts as a crew seat for occupancy, but there's no exterior hatch. With KIS/KAS it doesn't really matter. I've installed docking ports on inaccessible parts and docked with them and also just "installed" the inaccessible part on the nose of my rescue vehicle if they were light enough for a single Kerbal to move.

I originally tried the game on the Xbox a couple months ago and thought the user control scheme was extremely awkward but the game seemed really interesting. I found that it was a port from a PC game and tried that on a 5 year old laptop an loved it on the PC. Then I found the mod community. My Xbox hasn't been turned on since early June.

If you are bad with computers you might try CKAN to deal with managing mods. It makes it pretty simple.

I've always chosen whatever is commanding the rocket as root and that module usually does not even have a construction port in it. This is the order I launched: {top of stack}[1.25 dome fairing][construction port][module 1][construction port][module 2][standard docking port][mk1-3pod (set as root in VAB) fuel & engine][decoupler][booster]{bottom of stack}

I used construction ports for the first time this weekend and ran into the root node problem. The problem port I fixed by changing the KIS settings to let my Engineer move 100T at 50m to yank the construction ports out of the problem area. For the second launch of the same design, all I changed was to add the small domed aero fairing over the problem construction port and that seemed to shift the root node to the fairing. So now I launch construction ports with covers if they are at the front end of my ship. Since they can act as a one time decoupler it's not a big deal to pop the covers before docking.

Reading about your mod's developmentwith CoM and spinning, have you considered two chutes balanced on either side of the the capsule? I know this would be more work to change the model to add a slot for a second chute, but it might be worth it in the long run.

I ran across an odd bug. I use a patch to add a screwdriver and 3 bottles of propellant to each seat. Due to the limitations on seats needing to occupied to keep their contents, today I added 300L per seat inventory to every part with crewcapacity >0 and shifted from using seat inventory for cargo, but still left the auto assigned screwdriver and Eva propellant as appropriate for a Kerbals's pockets. The bug was in the editor. The inventory of the last seat was empty and it's contents were loaded in the general pod inventory instead. This was consistent across every pod I checked, but I don't think I looked at 1 man pods. I didn't investigate further as I was done tweaking my install for the day and had a station to assemble. The pod inventory worked as expected. I just never launched a ship with full seats to see if I could assign parts to the last seat as I was launching mostly empty command pods due to lack of available staff and using pods mtched to stack size instead of crew needs. This is KSP 1.4.4 running whatever CKAN has as the latest KIS along with about 60 other mods. I'm away from my computer for the night so I can't supply logs until tomorrow. EDIT TO ADD: NEVERMIND: I found this is only an issue with editing older craft saved before I added the patch for a pod inventory, newly built craft or adding new parts to existing craft don't have the problem. I ran across it editing a space station that had half a dozen crewed parts and those were probably the only parts I checked yesterday. Honestly this is such an isolated case, that I don't think it's worth chasing.

I just installed this today. Two comments: Is there a right way up for the parachute? It seems a little confusing installing it, but I haven't flown it yet to see if it matters. Maybe change the stripes on the part to chevrons or arrows to indicate up, ////\\\\ instead of ||||||||. Also, could a patch be added to the KooseCradle for ConnectedLivingSpaces compatibility at some point? I've patched it locally for now. @PART[KoosSECradle]:NEEDS[ConnectedLivingSpace] { MODULE { name = ModuleConnectedLivingSpace passable = true } }

I don't think so, but I may be mistaken. I had originally set an action for deploying them and had switch to the right click menu for replacement pods, but I seem to recall I couldn't fire reused pods. I also noticed the cradle that's left behind after decoupling wouldn't persist and it seemed like the reused pods were attached directly the surface without a cradle under them. Overall none of these are issues worth fixing, to me the pods should be a consumable item. But it would be nice if the pods were a bit more crash tolerant. I'm think I have around 50% survive deployment when fired flat, if you give them any upward arc it gets worse. I was playing around with them on a rover on Kerbin and a 45 degree upward angle would destroy most (80%+) of the pods on impact. That doesn't seem right to me.