Bug #18801

Incorrect Collisions with mk3 Cargo Ramp

Added by KerikBalm about 3 years ago. Updated about 2 years ago.

Target version:
Start date:
% Done:


Core Game, Making History
English (US)
Mod Related:
Arrow u r green
Arrow d r red


Parts will often break due to a collision when passing through the open space of the part, despite other parts passing through without collisions.

Some examples posted to Imgur:
A stock rover:

The Science Jr. part colliding with the cargo ramp

Redocking the rover, with the science Jr. now gone:

A stock rover, with retracted "Gigantor" solar panels:

they break off when the "gigantor" intersects the plane of the rear of the cargobay:

Note: after repeating this multiple times, it is always the one on the left side (from the point of view of this image).
another example, this time breaking off when loading instead of unloading a rover:
Note that it is again only 1 panel on the same side.

Passing through slowly enough avoids these effects

Related issues

Related to Kerbal Space Program - Bug #18017: Mk3 Cargo RampClosed03/13/2018


#1 Updated by [email protected] over 2 years ago

  • Status changed from New to Confirmed
  • % Done changed from 0 to 10

Confirming that constructions similar to those in the original-report's images, in version 1.5.1 still have retracted panels break when the seem they should be clear of the cargo bay walls. See related bug #18017 for example craft. The speeds required for breakage do seem to be higher, now about 5m/s, double what they were in 1.4.3.

The damage seems to occur at the transition between the MK3 cargo ramp and the hollow MK3 it is connected to, and always on the starboard side of the ramp (the side on starboard of an aircraft using this ramp as its tail).

A different example with maybe the same cause is described at
A helicopter craft also showed only the starboard-side elevons breaking, and being F3 reported as colliding with the MK3 ramp below.

#2 Updated by JPLRepo about 2 years ago

#3 Updated by chris.fulton about 2 years ago

  • Status changed from Confirmed to Ready to Test
  • Target version set to 1.7.0
  • % Done changed from 10 to 80

Changes have been made up to 1.7. Setting this bug to RTT to see if it is indeed fixed.

#4 Updated by [email protected] about 2 years ago

  • Status changed from Ready to Test to Resolved
  • % Done changed from 80 to 100

Resolved with bug 18017

#5 Updated by chris.fulton about 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF