Nertea

Nah, it has a different cross sectional shape. In theory it should be overridden by my manually specified drag cubes, but it isn't! That's what I can't figure out.

It could be a reason. It's the kinda thing it would be nice to get squad to fix, if it wasn't so tough to reliably repro without with some cfg tweaking. All the parts have been scaled more or less accurately to each other. The absolute number may not be accurate, at some time there will be a Great Rebalance of NFC/NFSpacecraft

Already tried that, even removed the whole cargo bay module.

I think the actual problem is (from much reading in the forums) that the occlusion system works by determining the drag area of the "back" of the cargo bay and subtracting that from the drag area of the "front" of the part behind it. This points to some kind of flaw in the way the object's drag cube is being calculated. However, I quite literally spent 4 hours last night testing, tweaking and testing again. I just can't seem to fix it. I guess I'll try again tonight, but I've literally rebuilt the unity file and cfg from scratch, both based off the mk3 bay now, and I have no answer. Even just forcing the drag cube to be the same as the fuselage doesn't seem to work! About the only functional difference at the moment is the fact that the Mk4 bay opening animation is reversed compared to the Mk3 ones. That seems like it would be odd to have that cause the problem, but... I guess? This is all weird.

@Jarin: Here you go Changes you should see: New drag cube for Mk4 Shoulder Intake Fix for cargo bay node occlusion Fix for large cargo bay's occlusion testing spheres Reduced air intake ratio of lift fans in LF mode (22 -> 14) Reduced all fuselage body lift values by 33% To others: not an official build, don't download unless you want to test.

If you're willing to be be a guinea pig, I can compile a test version and dropbox it now. With the caveat that I'm at work and therefore can't test, so it might not work great

Oh dear I think I might have found the problem. This is from the mk3 cargo bay in 1.2+ nodeOuterForeID = top nodeOuterAftID = bottom nodeInnerForeID = top2 nodeInnerAftID = bottom2 This is from the mk3 bay previously... nodeOuterFore = top nodeOuterAft = bottom nodeInnerFore = top2 nodeInnerAft = bottom2 It very much appears that they changed the specification string for the nodes there between versions. My definitions are using the old one, of course - that's not something I expected to change. This would explain all the problems, and would also explain why it wasn't a noted issue before (it just plain didn't exist). This would essentially mean that the internal node wasn't getting marked as occluded properly ever. An empty node means that it would look to the engine like there was nothing attached and that there was a virtual blunt surface in the bay. I'll test this when I get home.

@Jarin, @sh1pman: Ok, let me confirm, the bug sums down to this: Any part attached behind either any of the three cargo bays (and drop cargo bays?) is not properly occluded unless it is itself a cargo bay. If so, can I ask a few more questions? Does this also occur with things behind the Crew Cabin? Does the Crew Cabin (when placed behind a cargo bay) also incur huge drag? Is there a difference in drag between these three situations: Cargo bay followed by a tailpiece, with nothing in the bay Cargo bay followed by a tailpiece, with an object attached to both "inner" cargo bay nodes Bonus question: are the objects attached to the inner nodes properly shielded? Cargo bay followed by a tailpiece, with an object attached to one of the "inner" cargo bay nodes (preferably the rear one) Bonus question: is the object attached to the inner node properly shielded? I hugely appreciate the help by the way. Too many people report a bug and don't assist in the tracking of it, you are greatly helping me here.

No problem. Thanks for the help, it's a relatively easy fix I think. Next release should have the following: Fixed both long cargo bays' occlusion lookup spheres Forced drag of shoulder intake to be lower Reduced all lifting surface values by 50% Still the drag issue on the tail to deal with. Can you confirm at all whether the huge numbers occur with the Armadillo or Skate versions? Oh, hmm. Including the medium cargo bay? And by normal we mean something in the couple hundred kN range?

I don't know why the tailpiece is producing so much drag, that's a separate problem. The problem I'm describing is where the tailpiece is counting as inside the large cargo bay, but not the small one. @Jarin, KSP does occlusion tests for everything in the lookup sphere, if the sphere is misconfigured then it will look too far and start including things it shouldn't. The actual occluded volume should still be defined by the bay itself.

That seems to have tracked down one problem. Cargo bays are defined spherically, so the large cargo bay has a very large sphere defining its test radius. I can replace that with two smaller spheres which will more accurately model the bay area.

I do also appreciate input on these numbers. I kinda just took the approximate XY size of a Mk4piece and gave it a lift rating equal to an equivalent area of wings.

So confused about this now heh. I think potentially the ModuleLiftingSurface contributes to the drag numbers, which would explain the huge deviation with AoA.

Kinda but not really. The bug appears to occur when the heat content of the internal heat bucket is large (not really related to the core heat). So if you have a bunch of radiators, let them radiate away the heat from the large-mass parts, then save, you can avoid it. This is more or less why NFE stuff is configured to bypass this as much as possible by simply keeping things in the core heat bucket. Really the only sure-fire way to avoid it is to not have parts with high thermal masses be very hot on game save :S.

Yes. I think I answered you the other day, but for anyone else, there's an indication of this in the cfg file for each engine.

Helps if you make an issue on the repo. All the forum bug reports were lost when the old thread was killed, this demonstrates the value of putting it on the tracker. Maybe in 2018. I can't reproduce this is my test install. More information is required, such as a modlist and a log. This has to do with the stock heat redistribution system. When a vessel loads or even swaps between analytics mode and immediate mode ("on rails") the heat content is redistributed throughout the ship in a different way than immediate. Depending on the particularities of the algorithm, this can result in the heat content of a part with high thermal mass being averaged into parts with low thermal mass, thus increasing their temperature drastically. Because the reactors do contain a lot of heat, NFE has been relatively carefully tuned to avoid this or at least minimize it. If you're tweaking things and editing values I can't really say what combinations of thermal-affecting parameters may be causing it to appear often. You see this bug anytime you have high heat content parts, to be honest. It's relatively easy to reproduce with a few cfg tweaks, give an engine a stupidly high thermal mass and heat output, build a ship with a few " sensitive" parts, run it up for a while to heat things up, then save and switch vessels (or even just kick things up to high timewarp). There's a decent chance that it will redistribute the heat on reload and kill the sensitive parts.

I think you are on your own here. Probably a mod or version conflict, neither me or anyone here seems to be able to reproduce this. So I stuck the Mk3 cockpit on the front of the test ship saw it generating ~70 kN of drag at around the same speeds. Considering that the Mk4 cockpit has about 2x the front cross-section area, 150 kN seems fine. So that's alright. The shoulder pieces are a bit different. Looks like the shock cone has a custom drag model that makes it very much less draggy than the shape should be. That I can probably adjust. Would you say the crew cabin is resolved, at least? I'll check this when I can. The problem is that firespitter doesn't like multimode engines much, I tried to hack it to do so without much success.

I can't see any obvious problems that would cause it from the file list and the log. Does this occur with the normal NFE reactors?

No worries, I thought it was fine too. Better safe than sorry I guess.

It's not needed but could be helpful if someone still has an old patch file around. The bits that were omitted were as follows: !MODULE[FissionReactor]{} !MODULE[FissionGenerator]{} !MODULE[RadioactiveStorageContainer]{} Which just made sure to clean up any versions of those modules that were patched by USI before.

Not until it's updated. Can you check to see if @Omnipius's solution is yours as well? I'll make sure to restore the old-USI-patch cleaning lines in the next update just in case.

That's just unix vs windows line endings. I think I found the problem - the pull request I accepted removed a couple of key lines in the cfg. I'll make a fix later today or tomorrow.

Are you sure you don't have any remnants of an old build from either mod hanging around? I had a user PR make a bunch of changes to the integration to tweak some minor things, I guess it's possible something broke. You should read the FAQ! Q: CKAN Support Questions?A: Talk to CKAN folks, CKAN is not supported.

Mark IV Spaceplane 2.3.4 Marked for KSP 1.2.2 Updated CRP to 0.6.4 Updated MM to 2.7.5 Updated B9PartSwitch to 1.5.3 Updated Firespitter to 7.5.1 Updated DeployableEngines to 2.1.0 Fixed node size issue in SCIMITAR cfg Some tweaks to Crew Cabin drag parameters Fixed a MM path throwing errors on startup

There is a USI patch that does... something. If it needs attention, a pull request would be nice, I don't know what USI-LS requires. The unity files got nuked when I upgraded my dev chain (porting to 1.1 IIRC). They were painstakingly rebuilt which was why the 1.1 release took like 4 months. The reason nothing new is happening is because I don't really have interest in working on this mod these days. All available dev time is dedicated to "finishing" NFT at the moment.