Search the Community

In KSP2 is there an option for part clipping, or a work around? Probably the old tiny truss gimmick. I know it's very early access, but let's see what's out there. Because someone will ask "why", I just want my rockets to look nice.

Hi Kerbonauts! :) When playing KSP, at some point I learned that you can use KAL-1000 to generate infinite thrust and fuel. It was fun at first, but very soon made playing the game non-immersive. If I can go anywhere with ease, it's not a challenging anymore. Taking away the struggle of a gravity-bound flight, you basically defeat the main boss of the game. That is why I want to CLIP the result values of the controller, so cheating is not to be possible. That should regain me will and joy of playing. :)

https://www.xbox.com/play/media/CYBU4RE3 The video ain’t uploading, but that rover rocks side to side while driving and parked. I think it’s something with the wheels, but I don’t know. The drive limiters are turned down and the traction control is turned to 3 if that helps.

I haven't been able to find anything about this yet, and I haven't run any tests because it's easier in zero G. Has anyone attempted clipping different sized docking ports together to basically make a universal docking port? I already have a couple vessels in orbit with this concept but have yet to use them.

I've found that complex robotic installations used as wheel mounting points can be very shaky and reduce the wheel output by up to 80%. And I mean in the weird part clipping jitter way, for example a servo-hinge joint jumps all around the place non stop. If the devs could fix it that would be great.

Ugh. In flight part clipping is so annoying. Post your struggles here

This seems to have been introduced in KSP 1.3.1. Some wheels bounce harder than others, but all have some bounce. The large gear seems to have the least noticeable bounce, but it's quite noticeable at Minmus. The others are very noticeable back at KSC. The small gear seems the most stable. To avoid scrolling down, here are current bug reports filed on this problem. Please upvote these. https://bugs.kerbalspaceprogram.com/issues/16159 <- Surface collisions on physics start https://bugs.kerbalspaceprogram.com/issues/16090 <- Related to prerelease bug #15796 Non-active vessels jumping on load still happening on 1.3.1 A workable workaround to this problem, courtesy of @whale_2

Can someone tell me definitively how struts and fairings in the stock game are supposed to interact? I recently found myself fighting against KSP 1.3.1 to keep my struts where I want them. The game seems to treat these interactions inconsistently depending on the order you place/edit parts, whether you use Undo, etc. Some scenarios I've observed on a recent craft I was constructing: Connecting struts before fairings built Works fine Connecting struts through fairings after they are built Works in the editor most of the time, except: Occasional inconsistency within symmetry groups e.g. Sometimes when connecting the end of a strut to a surface inside a fairing, even though the "seed" strut I'm placing goes right through the fairing, I notice the mirrored strut terminates prematurely when it hits the fairing surface. The ship in question is symmetric across the relevant planes so there's no good reason I can see for the behavior to be inconsistent. Manually placing the struts individually at the same locations, without using symmetry, works fine. Trying to strut from a part inside one fairing, to a part inside a different fairing, usually doesn't work. Varying behavior, either: The game simply "deletes" the strut when you try and place it Or the editor "picks up" the part you are trying to pin the end of the strut to, detaching that part (and its children) from your craft (very annoying). Or it works in one direction but not the other (e.g. see above spoiler). Not sure if this is intentional. If so, it's a pretty naive attempt to prevent prevent the player from doing this as there are many ways around it. I've noticed cases where if you've already set up a situation like this (e.g. by running the strut before the fairing was built) then it totally screws up your ability to place struts anywhere on your craft afterward. All new placements start exhibiting one of the two aberrant behaviors above (strut is immediately deleted, or picks up target part instead of pinning strut). When I started seeing this, it seemed consistently reproducible. Reloading the game / craft didn't help. You need to delete the offending strut(s) to make new struts work properly again. Disconnecting and reconnecting a fairing base without deleting / rebuilding the fairing Doesn't seem to affect struts that pass through it Undo / Redo DISASTROUS results - seems to trigger "regeneration" of all struts in a manner that makes them consistently end at the first fairing surface they hit. Launching from VAB/SPH Maintains strut connections / orientations from VAB? (I know older versions sometimes reoriented your struts sending them flying out at weird angles but I think they fixed this one). Loading craft in Editor Maintains the saved strut connections (no "regeneration" trigger). Loading / Quickloading craft in flight Maintains the strut connections the way they were on your craft when you saved (I think). Much of the red behavior feels buggy and ill defined. If it's the intent that struts aren't allowed to pass through fairings, then all of the above user actions (except loading a craft in flight) should act the way the Undo button does - i.e. trigger strut "regeneration" and check for collisions, truncating them at the first surface they hit. Otherwise, the Undo thing really needs to be fixed, as well as the edge cases above. I'd be OK with defining different behavior for struts placed before / after fairings are built (this would seem to offer the player the most flexibility as to whether they want to strut through a fairing, or to the surface of one) but then the game shouldn't go mucking around with previously placed struts which I connected before I built my fairings. If it does want to re-evaluate my preexisting struts for new collisions (e.g. when placing a new part that may intersect the strut), then maybe it ought to keep track of which collisions existed before the operation began so those can continue to be ignored when the operation completes (particularly when less straightforward actions re-trigger said analysis). I think that would result in a more consistent and predicable player experience, where KSP wouldn't shoot you in the foot later by "helpfully" deciding on a whim to rejig your struts. I don't know if this behavior is new to 1.3.1. IIRC from the changelogs it looked like Squad was doing some work with struts in 1.3.0 and 1.3.1. I generally avoided stock fairings and tended to use Procedural Fairings instead (which seemed to behave in a more deterministic manner). But when the new release dropped, I decided to try playing without mods for a while (for unrelated reasons: to see if mods or the stock game was responsible for some performance issues I start to see after doing lots of launch / reverts in a row). The only mod I had loaded when I investigated all this was Kerbal Engineer Redux (KER) and I'm pretty convinced it's not causing the problems. I am not submitting a formal bug report, I just want to know how things are supposed to work and whether others are seeing similar behavior. (If so, I'd love it if a QA person from Squad could pick this up and run with it from here. Feel free to move this topic to another forum if appropriate).

Hello there, I am trying to build a Stratolaunch vehicle similar to the one in the Matt Lowne's video below. I noticed that he's clipping some parts, specially the wings, in order to make it look better. My problem is that when I try to do the same, parts collide with each other during take off and the ship breaks apart. I tried using struts to tie some of the parts together but it doesnt help much, also, I didn's see any struts in the craft on the video. I would like to know if there is something I should be doing to avoid that problem. Thanks!

The AE-FF2 airstream pro and likely other fairings are causing CTD on launch when there is any clipping at all and can corrupt a save as well, 0ing out funds in career and if the save manages to revert and saves to the persistent back up deleting the craft from the pad in the tracking center will result in a high pitch audible scream til the game ctds again. Rigorously tested while live streaming on twitch. The episde link is provided below and provides about 2 hours of test data showing different configs it was tested in. Oddly, the configuration worked once, normally in a engineering sandbox mode, and then crashed again when almost the same exact vehicle was reloaded and the same modifications were made in career mode. All parts were rigorously tested to confirm it was not a part issue of any sort whether stock or mod as they would all load to the pad independently just fine it was just when they were brought together in a fairing in a particular combination that this very serious crash style occurred. I suspect it has something to with fairing / engine interactions with colliders but even inverted the error still occurred. Submitting error reports generated by the game as well as a twitch tv link to the video where I attempted to diagnose the cause myself. I also suspect it may have something to do with the game thinking the craft is somewhere else for some bizarre reason other than the launch pad because it always switches scenes to space wtih 0 coms though still showing the stages on the left as if it never left the pad. The interaction is with KSP Intersetellar Extended Candle engines, but could conceivably happen with others though I ran out of time to test that theory. Here is the logs, the save files associated with the repeated testing CTDs: https://www.dropbox.com/s/qebzscrjgn1bvmn/05092017errorlogs.zip?dl=0 Here is the video on Twitch TV that contains the troubleshooting effort. It starts around 2:15 to 2:30 and runs until the end about 4:30, a full 2 hours of rigorously attempting to identify and troubleshoot the problem. Inverting the payload in the fairing hangar also did not solve the problem. https://www.twitch.tv/videos/141246182 Craft file causing the CTD: https://www.dropbox.com/s/7ywx2gx5uub7bgd/Micro Probe 2.craft?dl=0 update: An even more bizarre complication has arisen, this craft can be launched in sandbox, it only crashes in career. Repeatedly tested in career, with and without the decoupler, with and without the fairing, with and without it being at the bottom of the inter-staging rack. Unbelievably odd. It has to do something with the name and perhaps the initial game crash? Going to destroy the craft in this particular save, rebuild it from scratch, rename it and see what happens. Rebuilt it exact to spec under a new name, still crashes in career only, new name Mun Micro Probe 2. The original craft that it was based on is also crashing. We're making progress in narrowing down cause. Updating title. Suspect previous deletion of a probe in space did not complete properly in the tracking center corrupting the save and possibly making it so that all probe cores of the same type launched now register at a random point in space rather than at launchpad. Left the name unchanged, stripped down to probe core, launched. Stable with just Hecs core, went back reloaded primary craft file so that once again all parts were present, launched, ctd. Something is broken on the payload, still working out what. This craft launched before with no problem, something has changed. Removed all parts from corrupted craft that were mod-based and only utilized its stock part elements, the craft deployed without crash. Adding back the navigatin light and launching, then adding back the candle engines and launching, will update again momentarily. Navlights confirmed good. No crash. Re-add candle engines.. no crash? Craft is mysteriously stable again as a whole after re-add of parts. Possible issue with saved crafts from between KSP IE updates. Removed and re-added candle engines to the full payload/delivery booster assembly and still crashing, so re-adding the engines does not always fix whatever is underlying this. Debugger menu will not open when the view is changed to space prior to ctd and funds are wiped. The crash dumps are indicating some form of bizarre memory access error. Putting ksp into admin mode. But why only affecting this particular craft file and why only career? Craft loaded without crash after 3 way coupler removed, landing gear, candle engines, and the nav lights were removed. Adding back only sm-3 mount and putting on the fairing rack and reloading. Still stable. Adding landing LT-1 gear back to the sm-3 mount, retracted as before. Normal launch. Adding back candle engines. Normal Launch? Adding back nav light. Normal launch! ...... Conclusion: KSP not running in admin mode was causing a random failure to access some part of the craft file for reasons that are unexplained as all the parts in this build have been utilized before. This began after the recent ksp ie mod update, so uncertain if interaction has been caused by updates. Solution: Run KSP in admin mode, this was not a part or apparent staging/physics error. Why it has chosen to randomly manifest a memory access error now remains undetermined, but launch is able to progress without error.

I made a craft I was pretty proud of, it was supposed to be the backbone of my charter fleet. It works perfectly, it has got range, it is easy to pilot, it can reenter... Just minimum clipping actually but indeed I moved the wings with the SPH gizmos. The problem is that whenever I am already in orbit if I get back to the space center to arrange for another launch or any other KSC related activity and then I try to fly again the craft, the outer section of the wings gets ejected. Pics below, the issue is depicted in the fourth one. Has anybody experienced such an issue before? To me sounds like a clipping issue, but even if I tried to move everything I could not find the guilty part. If anybody feels like to have a first hand look, here you can download the craft; it is full stock. To reach orbit just pitch 5° at take off (1 to toggle the ramjets) and keep it straight. Add nukes at 19000 pressing 3. Jets will go out just a little bit over 24000, toggle intakes with 2. There isn't any external fuel line to save on drag so you will need to move the fuel manually from the wings to the inner tanks to feed the nukes. I do not have any "major" mod installed, just a few for aestethics and mechjeb. I am not even sure this is the right section where to post this, I apologize if I made the wrong choice. Thank you in advance for any feed back on this.

I've heard that 1.1 is very sensitive to problems caused by clipping. These days, I try hard to not intentionally clip any parts. However my space plane wing is comprised of 4 big S wing panels. Previously, I'd attach the first wing to the fuselage, the second wing to the first wing, and the third and fourth wing sections would attach to the second. However, there is not (yet) a Kerbal joint reinforcement nor a Tweakscale for 1.1 release, and this configuration flaps quite a lot in flight without Kerbal joint reinforcement. Hardly surprising, since my tree structure has one wing panel bearing the flight loads of all the others, and the outer wing panels are 4 nodes away from the root part. So, I thought I'd rework my design to try and get it as stock and mod-free as possible. I removed the front pre-cooler pair, replaced with reversed tail cones (flight testing revealed one pair of pre coolers is plenty to run a Rapier and Two Panthers). Then experimented with attaching more of my wings direct to the fuselage, to reduce the flapping. However you can't attach wings radially to engines and there is now only one pre-cooler per side. So one wing attaches to the pre-cooler and one attaches to the cone at the front of these nacelles. The problem is, the cone is at an angle as will be the wings, and it all looks a bit of a mess. Will I be storing up problems for myself if I allow the wings to clip inside each other in places to seal up the gaps between non-aligned wing panels, how far do things have to clip inside each other to be a problem? Or should i just put up with the flapping as "cosmetic". At least it looks like it's trying to help you get to orbit.

Hello everyone. I just wanted to see if this was a reported issue or not, I searched but couldn't find any reports. Problem: the drills seem to start to clip through the ground as intended when they deploy But, after say 3ft under they seem to encounter a solid as if they aren't clipping though anymore. I'm wondering if its one of those 'ingame invisi walls' to stop things falling though the world? I used Hyperedit to move the base to another location on the Mun but had the same result. In 1.05 I don't remember this happening, has the item changed that you have to attach higher up? Items used on the drill module are: 3x structural fuselage. 2x clampotron. 12x m-1x1 structural panel. 6x radiator panel sml. 6x radiator panel (edge). 3x thermal control system (medium). 6x drill-o-matic. Not Deployed drills http://i.imgur.com/ocgZaQZ.png Deployed drills http://i.imgur.com/UKDMvkZ.png I had mods installed initially. I uninstalled them (except mechjeb as it is the only one attached to the modules anyway) Details. KSP ver (copied from C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program) build id = 01183 2016.04.02 at 03:20:46 CEST Branch: prerelease PC: Win7 sp1 64-bit 8G ram Intel i7 [email protected] Nvid Geforce GTX 760 let me know if its intended please so I can remove the module and relaunch a revised module, thanks. I decided to raise the drills higher and there isn't any problem anymore. [MODS] if its intended then u can by all means discard this post and delete it.

Hello guys, I have a big problem with my Minmus Refinery I built. It was planned as a huge fuel supply for my orbital station. The building process was pretty long inculding some errors and fixes but in the end it worked out and I had my facilty completed. It wobbled a bit upon loading and shaked due to some clipping errors with the drills but nothing crucial until the tanks got heavier because of fuel getting loaded into them. I created an album to show my problem. I wanted to know if I can edit the safegame file in a way that the tanks are on the exact same level as the root part to avoid clipping into the ground or if I can change the root part to the lowest part. Also will this bug be fixed in the next version? In my opinion the altitude of a vessel from the ground should be calculated by the lowest part, not by the root part. Please help, I spent a whole week building this and its pretty frustrating. I can edit the safe file and lift the whole facility in the air a few centimeters to prevent it from exploding but I have to do this EVERY time I approach it or load it. Any hints? Also I uploaded the safegame (I excluded everything except the vessel, which is still a lot of code): http://www.file-upload.net/download-11408640/refinery.sfs.html

This question is almost certain answered elsewhere here. What parts, when used on the same craft, are able to touch the craft? By touch, I mean "not pass through."