alphaparrot324

Apologies if this has been brought up before, or if it's a known bug with a workaround, but my own searches didn't turn up anything. I have noticed for some time now that if I put the tail ramp on a craft, when I switch focus away from the craft, upon switching back, the ramp is *always* open, regardless of what state I left it in. It claims to think it's open, but if I toggle the action group to close it, it doesn't close (as if it's switching from closed to open rather than open to closed), and it takes a second click to close it. So somewhere in the code, it knows it should be closed, but that's not consistent with the game thinks its doing. I have not noticed this behavior on any other parts, but it's extremely consistent with the tail ramp. Any ideas?

So I've got good news and bad news related to the wing occlusion I reported with regards to the tail cargo ramp. The good news is that erroneous wing occlusion does also happen with entirely stock parts. The bad news is that with stock parts, the wing parts have to be flush against the cargo bay, such that the wing centroid is likely to be computed as being inside the bay or something. I've posted a report on stock wing occlusion in the master thread for parts not activating while stowed (which is the exact same phenomenon--parts occluded by the cargo bay get flagged as being stowed or occluded, and engines don't fire, intakes don't work, and wings don't produce lift). With Nert's tail ramp, I don't have to have the wings touch the cargo bay at all--which suggests that something is a bit wonky with the part geometry or the raycasting through and within the part, and that's exacerbating the cargo bay occlusion issues--making it happen when it otherwise wouldn't. From what I understand of Harvester's explanation of the new cargo bay occlusion, parts whose centroids are within the spheroid enclosing the bay are considered, and if the part centroid (the visual center of the part, unrelated to part mass or density) lies within the bay (computed by raycasting--if the ray from the centroid to the cargo bay centroid hits a wall or a trigger, it's outside the bay), then it's occluded. So either somehow the tail ramp centroid is being computed in a weird way, or, more likely, the raycasting computation isn't detecting the wall of the tail ramp for parts that are close enough to the bay. With the stock parts, it seems that the centroid actually has to have a chance of ending up on the other side of the bay wall (for wings--intakes and engines don't have to be so close). Not so with the Mk IV tail ramp. I experimented a bit more (as shown below), to see at what point the occlusion goes away, and it is related to the distance from the tail ramp. If I give a bit more clearance, the wing parts on the edges are not occluded, but the central one, which is closer, is still occluded. If I give a lot more clearance, as I did with the B9 wings, then the wings work fine. So for whatever reason, the maximum distance at which a part centroid is computed to be within the cargo bay is, for this part, further than the edge of the cargo bay. So it seems that while the occlusion bug is a stock bug, there might be something wonky going on with the Mk IV tail ramp that's making the problem worse.

I've identified another manifestation of this bug, and this builds off of the intake occlusion behavior noticed by Clouds, and is related to the phenomenon Ferram was concerned about when Harvester first posted the explanation of how cargo bay occlusion now works (with regards to part centroids ending up clipped or flexed into cargo bays and making the entire part occluded). When wing parts are too close to the cargo bay, specifically it seems when the part centroid is flush against the external side of the cargo bay, the wing part is considered occluded, and produces no lift. Open the cargo bay, and the wing part works. This does not seem to depend on if the wings are on the door side of the bay or not, and seems to be a problem with cargo bays in general. I first noticed this problem with Nertea's Mk IV mod, when wing pieces too close to his tail cargo ramp did not produce lift (my post here). That might be a more complicated problem related to possibly wonky geometry in the mod, as it does not require the wing parts to clip into the bay at all, but I was able to produce similar/related behavior in a completely clean stock install of KSP 1.4, with both Mk2 and Mk3 cargo bays. This suggests that part activation problems while apparently stowed (but not actually stowed) are really a problem with cargo bay occlusion. I don't know if it's a problem in computing centroid distance, or if it's a raycasting problem. Moving the wings a bit away from the bay does make the occlusion go away, so it's only when the wings are sort of in a gray area that this comes up. It does not have to be wing pieces attached to the bay, or to a parent part, rather wings part of a totally different branch of parts that have flexed too close to the bay also get occluded (which is exactly what Ferram predicted would happen with the new occlusion code). Wing parts do seem to have it better than engines or intakes, though, whose centroids don't even have to be close to the cargo bay for the part to be occluded. But this behavior does include wings--it's not just engines, parachutes, and intakes. And when wings that are expected to produce lift don't do anything... Bad Things happen.

Will do. First I'm going to see if I can reproduce this phenomenon using only stock parts in a totally clean install. I'm betting I probably can, but if we're going to pin this entirely on the stock occlusion code, I want the evidence to be rock hard​.

I've got another aspect of the occlusion bug to report. I'm finding that even when wings aren't attached to the tail cargo ramp, if they're just near it (specifically near the top), and the cargo ramp has been opened and then closed, the wings are occluded and produce no lift. I've been able to reliably reproduce this with both B9 procedural wings (how I first noticed it) and stock wings. I'm use stock aerodynamics. At first I thought it might be related to the weird thing where when you have a closed tail ramp, and switch focus away to something else (KSC, another craft, etc), and then switch focus back, with the craft in question leaving physics range, the tail ramp is magically open and needs to be "opened" again and then closed, but I've been able to determine that this happens even if you only open and then close the ramp, without doing anything else. And when those rear wings are occluded, they produce no lift (of course), which leads to Bad Things. Opening the ramp while in flight results in the rear wings once again producing lift. The wings in each case are not attached to the tail ramp--they're attached to vertical wing pieces that are either attached to other wings, or to the cargo section to the fore of the tail ramp. Not sure what can be done about it, or if this is something that will pretty much always be a problem and I just shouldn't have rear over-craft wings sitting so close to the fuselage. I've attached an album of screenshots documenting my experimentation with this. I'm also attaching my .craft files if anyone wants them for reproducibility reasons. https://www.dropbox.com/s/xw00ld8wohiqfts/KFC%20Osprey%201.craft?dl=0 (requires B9 procedural wings) https://www.dropbox.com/s/1vshehml5ad8peb/MKG%201.craft?dl=0 (stock + MkIV) Note that this one doesn't really fly well, it was just to see if I could get the stock wings occluded. You have like 10-15 seconds on the runway to experiment before it hits something and things blow up.

Turns out the Heavy Ram Intakes make for *excellent* pontoons. Looking forward to the full release!

Turns out designing planes like fish is hard. Which, after my most recent attempt went into an uncontrollable and nearly-unrecoverable spin, seems obvious--at high speeds, slight turns or wobbles will present the entire face of the craft to the oncoming air, inducing enormous drag. Maybe fish don't have to deal with this because water is incompressible, unlike air. Regardless, this poses a whole new set of challenges to spaceplane design that will be very interesting to tackle!

So um. Recent changes look really good. Especially love the fishhead cockpit--never thought of designing my spaceplanes like fish, but now you've got me thinking that maybe the fish are on to something with that hydrodynamic efficiency thing. Overall, big fan of this expansion pack. However, something wonky seems to be going on with the Fishhead cockpit. Plane flies great, but inevitably, I get up to a pretty good speed, and BLAM spontaneous disintegration, in a very spectacular manner. As far as I can tell, it's not overheating, and the last time it happened was right around Mach 1, though I've had it happen at slower speeds. Seems to be a collision with Right_eyetransform or Left_eyetransform, whatever those are.